\uGWAda Help Engine\n \vAbout the GWAda Developing Environment\v10. \vAbout this help\v11. \vEditor Commands & Monitor Information\v12. \vTable of contents - LRM\v13. \vAlphabetical Index\v14. \vHow to use this Help Engine\v15. \uAbout the GWAda Developing Environment\n GWAda is a development environment built around the NYU AdaEd inter- preter. It allows the editing, compiling, binding and execution of Ada 83 programs. 1. To compile a program: Activate the top menu (F10) and select the Compile option. 1.1. To compile the current source: Activate the option "Current Unit". The source that will be compiled is the one that is being displayed on the screen. Be sure to setup properly your working directory. This is achieved by making of the "Directory" option within the "Option" top menu item. 1.2. To compile a source that is not being edited Activate the option "Select Unit" and enter the file path. Examples: C:\my_prog.ada C:\others\*.ady Hints: Save the directory setup (activate "Write" within the "Option" top menu item). The setup is saved in your current directory onto file "GWADA.OPT". When this file is not present the default setup is assumed having the current directory as the " Source Directory" and the sub- directory "ada", within the current directory, as the "Library" directory. Before compiling any program you must create a library. To create a library select the "New Library" option within the "Option" top menu item. 2. To bind a program select the Bind option (at the top menu). A set of units available for binding will be shown. Select one at each time. The unit selected will then be binded. The active binded units are ready for interpretation. 3. To run a program select the Run option (at the top menu). A set of units available for interpretation will be shown. Select the one you want. To modify execution parameters (for the Ada interpreter) use the Parameters sub-option within the Options top menu item. To activate the monitor use the Parameters sub-option. \uDisclaimer\n This program is distributed free of charges for educational purposes only, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Please send your comments and/or suggestions to: Dr. Michael B. Feldman EECS Department The George Washington University Washington, D.C. 20052 mfeldman@seas.gwu.edu Dr. Arthur V. Lopes Departamento de Engenharia El trica - Escola Polit cnica - Pr dio 30 Pontif cia Universidade Cat lica do Rio Grande do Sul - PUCRS Av. Ipiranga 6681 90620 Porto Alegre - RS / Brazil vlopes@vortex.ufrgs.br \uAbout this Help\n The LRM (ANSI/MIL-STD-1815A-1983) was transformed into this on-line help system for use with the GWAda Development System by: Ulrich Peters Jerry Dressler Rafael Presotto supervised by Dr. Arthur V. Lopes Pontif cia Universidade Cat lica do Rio Grande do Sul, Brazil \uEditor Commands & Monitor Information\n Here you will find a summary of the operations allowed by the GWada multi text full screen editor. The GWAda top menu becomes visible by depressing either the F10 or the ESC key. The editor works under two modes of operation: -Insert (Ins) -Overwrite (Ovr) with up to 8 text files (to increase the number of text files change "#define AVL_MAX_WINDOWS 8"; this define is located within file "edit.h"). You may perform cut and paste operations among any of the editing text files. To open a text file depress the Alt-F O keys. To flip among open text files use the Alt-W keys. To close the current text file use the Alt-F C keys. The current text file is the file whose portion is being displayed onto the screen. The above operations may also be performed by using the top menu. The top menu is activated by depressing the F10 key. To return to the editing mode depress the ESC key. You are right now under control of a restricted execution of the editor. You can test many of the editor options while you read this text. The operations allowed are shown below: Key Description/Action (Upper and lower case letter keys have equal meanning) Arrows Allow to move the cursor left, right, up and down. PgUp Moves the cursor one page up. PgDn Moves the cursor one page down. Home Moves the cursor to the text line begin. End Moves the cursor to the text line end. Ctrl-V Ins Changes from Ins mode to Ovr mode, and from Ovr mode to Ins mode. Del Deletes the current character. Backsp The backspace key to the left of the current character. Ctrl-N ENTER Creates a new line. Tab Insert up to k spaces according to the cursor location. The default identation lenght (k) is 4. It can be altered in the Options top menu (Alt-O I). This will also change the formating style when using the F7 key. F1 Help on Hot Keys. F5 Go to a specific text line (user is prompted). F7 Generates package body templates from package specifications. Task body templates are also generated from task specifications written within a package spec. Before depressing the F7 key first position the cursor over the PACKAGE keyword that starts a given package specification. Only then depress the F7 key. Answer Y if the template is to be appended to the end of the corrent editing text. Otherwise you will be prompted for the name of the file that will contain the resulting package body template. The template will be inserted into this file. While this option performs some syntax check,it is assumed that the package specification is correct. F8 Search Help on the LRM. In the editor mode press the F8 key when the cursor is over a word. If this word is in the LRM index you will be given a menu with the matches for that word. Select one of the entries and the related LRM text will be displayed. F10 Brings the GWAda Development Environment Menu (Top Menu). ESC Returns to the editing mode from the Top Menu. Ctrl-y Deletes the current line (idential to Alt-E D). Ctrl-g Deletes current character (identical to Del key). Ctrl-k b Mark text's block begin (identical to Alt-E M). ******** The second key, as "b", above should be depressed without holding the Ctrl key. Ctrl-k k Mark text's block end (identical to Alt-E M). Ctrl-k c Copypreviously marked block (same as Alt-E C). Ctrl-k s Saves the current file. Ctrl-D Moves right. Ctrl-Left Ctrl-A Move back one word. Ctrl-Right Ctrl-F Move forward one word. Ctrl-Q R Move to begin of file. Ctrl-Q C Move to end of file. Ctrl-Q Y Delete from the current position to the line's end. Alt-F F2 Activate File menu. Alt-F O Opens a file for editing. Alt-F C Closes the current file being edited. Alt-F S Save the text to disk. Alt-F I Shows general information. Shift-F9 Alt-F D Starts a DOS shell. Alt-F Q Quits the program. Alt-F4 Quits the program. Alt-E Activate Edit menu. Alt-E I Inserts a text file to the right of the current cursor location. Alt-E D Deletes the current line. Alt-E F Scans the text looking for the first occurence of a string. Alt-E R Perform text replacement. Alt-E M Used to mark a block of text for future duplication or disk transfer. Alt-E C Inserts a previously marked text block. Alt-E W Creates a disk file containing a previously marked text block. Alt-E S Allows the insertion of special ASCII symbols. Alt-C Activate Compile menu. Alt-C C Compile the current text file. Alt-C S Slect a non editing text file for compilation. Alt-B Activates the Bind menu. Alt-R Activates the Run menu. Alt-W Activates the Window menu. Alt-W n Sets the text file name, n, as the current editing file. Alt-O Activates the Option menu. Alt-O D Used to set the source file and library directory. Alt-O M Access the monitoring/debugging tools. Alt-O F Used to set compiler and interpreter options. Alt-O C Allows to customize the editor/environment colors. Alt-O I Used to set the identation size (default = 4). Alt-O R Reads in the options file previously saved. Alt-O W Saves to disk the current options. ALt-O S Overwrite current options with the default options. Alt-A Activates the Ada menu. It allows text insertion of language constructs. Alt-H Activates the Help menu. Alt-H H Brings the Help engine. Alt-H F Show some of the hot keys (same as F1). Dr. Arthur V. Lopes Departamento de Engenharia El trica - Escola Polit cnica - Pr dio 30 Pontif cia Universidade Cat lica do Rio Grande do Sul - PUCRS Av. Ipiranga 6681 90620 Porto Alegre - RS / Brazil vlopes@vortex.ufrgs.br lopes@seas.gwu.edu \uMonitor Information\n The GWUMon Parallel Ada Monitor provides a shell around the NYUAda Run Time System(RTS). This monitor allows the user to set tasking options for the RTS, and to monitor the execution of the RTS. This monitoring shows the source code for the program which is running, or the execution percentage of the various tasks of the current program. \uIntroduction\n This is an introduction to the GWUMon execution shell. This shell allows a user to interact with the NYUAda Run Time System (RTS) while the RTS is executing the user program. This interaction with the RTS allows the user to see the program statement as they are being executed, and to monitor the CPU as the program runs. This README file walks the user through an initial run of the monitor. Note that there are several Ada programs which are given with this distribution. One of them, TEST1.ADA, will be used to give a walk through of the system. \uSystem Setup\n IF YOU HAVE NOT PREVIOUSLY INSTALLED NYUAda or GWAda If you have never installed NYUAda or GWAda, then use the following directions to install the GWUMon system. First, make a directory where the programs which will be used by GWUMon will be stored, and change to that directory. It is suggested that the directory "ADAED" be used. Assuming that this directory will be named "ADAED" and will be on the "C:" drive, this can be done by typing: c: cd \ mkdir adaed cd c:\adaed The programs which install GWUMon are contained in a self extracting archive called GWUARC.EXE. This is a selfextracting archieve. To load the GWUMon system, simply run the archive executable. Assuming that the archive is on the "A:" drive, type the following: c: cd \adaed a:\gwuarc The GWUMon system should now been installed. Several system variables need to be set or changed to run the ADAED system. A batch program, MONSETUP.BAT, is included with the distribution. If you wish, the following instructions will allow you to use the GWUMon without modifying this file. Otherwise, this .BAT file will give you instructions on what needs to be modified in your AUTOEXEC.BAT to allow GWUMon to run. If you are not going to modify MONSETUP.BAT, then the following instructions will allow you to setup your computer to run the monitor. One time only, type the following: c: cd \adaed monsetup mkdir myprogs cd \adaed\myprogs Each time you wish to edit or compile and modify a program, always make sure that you have run monsetup, that you are in the "\adaed\myprogs" directory, ie: c: cd \adaed monsetup cd myprogs IF YOU ALREADY HAVE INSTALLED NYUAda or GWAda If you already have installed NYUAda or GWAda, you probably are familar with how they work. GWUMon is simply an additional shell to be used around ADAEXEC. Therefore, these instructions will assume that you are familar with NYUAda. First, change to the directory where you have stored NYUAda or GWAda. Save the files in this directory. GWUMon will overwrite all the old NYUAda and GWAda files. Note that GWUMon uses NYUAda as a baseline, but it does not work with the unchanged NYUAda programs. Do not try to run GWUMon with any NYUAda programs which have not come with the GWUMon distribution. After you have saved the files in your NYUAda directory, unarchive the files from GWUARC. Since GWUARC is a self extracting archive, the files can be retrieve by simply running GWUARC from the directory where you wish to place the files. Once you have GWUMon installed, all your NYUAda and GWAda programs should work as before with only one modification. Since GWUMon uses a slightly different AdaEd interpreter, the library files are changed slightly. You should therefore make all your libraries new, and you will have to recompile and bind all your programs. \uRunning thr Monitor\n RUNNING FROM THE COMMAND LINE Although GWUMon was written to be integrated into GWAda, it can be run standalone from the command line. If you wish to do this, you should make sure that all your compiles include the "-a" option, ie: adacomp -a -b dummy.ada When you run GWUMon, the command line options are exactly the same as the options for "adaexec", so you should check the NYUAda documentation if you wish to set these options. Note that if you don't set the "-a" option in the compile, the monitor will not work. \uRunning from GWAda\n If you are running GWUMon from GWAda, you do not have to worry about any compile options, etc. GWAda sets them for you. From the command line, type "GWAda", and the GWAda system will start up. To run the monitor from GWAda, go to the options menu, and choose the option "Run Monitor". This is a toggle which turns the monitor on and off. If you choose not to run the monitor, the NYU AdaExec program is run as usual from GWAda. \uA First Run of GWUMon\n This section will give you a step by step walk through on how to use GWUMon from GWAda. 1 - Copy the ada program "TEST1.ADA" from the directory \ADAED to the directory \ADAED\MYPROGS 2 - Start GWAda by typing "GWAda TEST1.ADA" 3 - The GWAda editor should now be running, with the source for the program TEST1.ADA in the window. First, create a new library as follows: Hit the "ESC" key. Type "O" to select the options menu. Type "N" to select a new library. A New library has been created. 4 - You should still be on the menu bar. Type "C" to select compile. 5 - When the compile is done, you will no longer have the menu bar. Type "ESC" to bring up the menu bar, and type "B" to bind the program. 6 - You will be asked for the program to bind. Select "test1". The program is now bound. 7 - Type "O" to select options again. Use the down arrow key to select the option "Run Monitor". Hit enter to select this option. 8 - Type "R" to run the program. When asked what program to run, select "test1". 9 - You should now have up the monitor screen. We will use all the default options, except for the delay. This is the first field. Set this to 5 by typing a "5" followed by blanks until all the "0"'s are gone. Hit "ESC", and the monitor will start. 10 - Note that the monitor is now running, Windows with the source programs should be coming up titled "main", "task1", and "task2". 11 - Once all three windows are up, type "CTRL-D" to bring up the setup window. Use the "ENTER" key to go to the Window Type field (the last field). Use the down arrow key to select "Two Windows, Vertical". Hit "ESC" to leave the setup screen. 12 - The Control screen should now be up. Use the arrow key to go to task1. Toggle the "Window ON" (WON) using the "t" key. Do the same for task2. 13 - Allow the program to run. We have now gone through the basics of how the monitor program works. \uGWUMon Options\n There are many options which can be set in GWUMon. The best way to find out what they all are is to experiment with the system. This section will give an overview of what the options are, and how to use them. \uSetup Screen\n The set up screen is the screen which initially comes up when you run GWUMon. The following can be set from the setup Screen: Delay Rate - This is the amount to delay the monitor on each clock cycle. Note that a clock cycle is one pass through the interpreter. Cycles for Reporting Exec % - If Type of Monitoring is Exec %, then this tells how many cycles to run between reporting. Delay time - If the Type of Delay is set to Scaled then this is the number of clock ticks to be interpreted as 1 second. RR statments - If Type of Tasking is set to Round Robin, then this is the number of cycles between task switches. Type of Tasking - This is the task type model. It can be set to Round Robin or Run Til Blocked. Type of Delay - The type of delay can be either Real ( 1 second is a real time second), or Scaled ( 1 second is some number of clock cycles. Type of Monitoring - This can be either None (No monitoring is used), Line (show the lines of code as they are executed ), or Exec % (show the execution % for each task at the interval specified above). Line Trace - Turns Line Tracing on. This stops the monitor after each line on the current monitor screen is executed. Task Trace - Turns Task Tracing on. This stops the monitor after each task switch for a task on the current monitor screen. Type of Monitoring Window - Type of window to use in Line Monitoring Mode. You can show 1 - 4 tasks in 4 different ways. NOTE: Help for the fields in this screen can be gotten by typing a "?". The reason a "?" was choosen, rather than the normal "CTRL-H" is that a CTRL-H and BACKSPACE are equivalent, and the BACKSPACE is needed to edit the fields. \uControl Screen\n The Control Screen allows the user to choose which tasks they wish to see on the screen when the monitor is running. It tells the current status of the tasks, and allows the user to choose which tasks they wish to monitor. The field WON tells which windows are currently being monitored, if the field is "yes", the task is attatched to a monitor window. This WON field can be toggled by using the arrow keys to position yourself on the task you want to change, and typing the "t" key. If there are more then one screens worth of tasks, then hitting the down arrrow on the last task on the screen will bring up the next series of tasks. \uOptions when Line Monitor is Running\n Line monitoring allows the user to see what lines are being executed in each task as they are running. Many of the options which are available from the SETUP screen which pertain to line monitoring can be set with a single key stroke while the monitor is running. This is to save the user the time of having to go into the SETUP screen and change the options. These commands are summarized here: Up Arr - doubles the speed of the interpreter (ie. cuts the delay in half.) Dn Arr - halves the speed of the interpreter (ie. doubles the delay.) ctrl a - brings up the control screen to allow the user to set the tasks they would like to monitor. ctrl b - stops the monitor from running. This options allows the user to run their program without any monitor output. Note that the delay still is in effect, and the program can be slowed down or sped up. ctrl c or ESC - stop the execution of the monitor. ctrl d - Brings up the setup screen. ctrl h - Brings up the help screen. ctrl l - Sets line step mode, where the monitor stops after each line that is in a currently active monitor window has been executed. ctrl t - Sets line task step, where the monitor stops after each task switch that is in a currently active monitor window has been executed. The status codes for line monitoring are as follows: R - Wait on Rendezvous M - Rendezvous Meet D - Wait on Delay * - Task Ready to Run --> Task currently running Note that all this information can be obtained by typing "CTRL-H" when the line monitor is running. \uExecution Percentage Window\n The executions percent window allows the user to compare the relative number of clock cycles each task uses. The only option on this window is to turn the monitoring by using the CTRL-B key. \uKnown Bugs and Other Hints\n There are a number of known bugs and problems which can occur when using the monitor. These will be fixed for the next release. 1 - Too many key strokes which are not processed can cause the monitor to hang. For example, if you hit alot of DOWN ARROW keys to slow the monitor down, the system will take longer to process these keys, and eventually will hang. If this happens, the computer must be rebooted. 2 - The monitor comes up but no source lines are displayed and the task line is not advanced. This can be caused by the source program not being compiled with the "-a" option. If you are compiling from the command line, make sure you use the "-a" option on the compile. Charles W. Kann EECS Department The George Washington University Washington, D.C. 20052 ckann@seas.gwu.edu \uTable of contents - LRM\n 1 \vIntroduction\v100. 2 \vLexical Elements\v200. 3 \vDeclarations and Types\v300. 4 \vNames and Expressions\v400. 5 \vStatements\v500. 6 \vSubprograms\v600. 7 \vPackages\v700. 8 \vVisibility Rules\v800. 9 \vTasks\v900. 10 \vProgram Structure and Compilation Issues\v1000. 11 \vExceptions\v1100. 12 \vGeneric Units\v1200. 13 \vRepresentation Clauses and Implementation Dependent Features\v1300. 14 \vInput-Output\v1400. \uAppendix\n A \vPredefined Language Attributes\v1500. B \vPredefined Language Pragmas\v1600. C \vPredefined Language Environment\v1700. D \vGlossary\v1800. E \vSyntax Summary\v1900. F \vImplementation Dependent Characteristics\v2000. \uAlphabetical Index\n Abnormal Task \v A \v20. Attribute designator BASE predefined attribute) \v B \v21. Box compound delimiter CALENDAR (predefined library package) \v C \v22. CURRENT_OUTPUT (text_io function) DATA_ERROR (input-output exception) \v D \v23. DURATION (predefined type) Effect \v E \v24. External file Factor \v F \v25. Function specification Garbarge collection \v G \v26. Greater than or equal Handler \v H \v27. Hyphen character Identifier \v I \v28. Iteration scheme Label \v L \v29. Lower case letter Machine code insertion \v M \v30. Mutually recursive types NAME (input-output function) \v N \v31. NUMERIC_ERROR (predefined exception) Object \v O \v32. Overloading PACK (predefined pragma) \v P \v33. PUT (text_io procedure) Qualification \v Q \v34. Quotation character Radix of a floating point type \v R \v35. Run time check Safe interval \v S \v36. SYSTEM_NAME (predefined pragma) Tabulation \v T \v37. Type with discriminants Unary adding operator \v U \v38. USE_ERROR (input-output exception) VAL (predefined attribute) \v V \v39. Visible part (of a package) Wait \v W \v40. Writing an output file Xor operator \v \v41. YEAR (predefined function) \u How to use this Help Engine\n You can operate this hypertext program with your keyboard or with a two-button mouse. For best visualibility, you should use a color monitor. \uButtons\n \uF1\n Returns to the main help window. \uALT-F1\n Returns to the previous help window, if any. \n Allows to select keywords in the current window. \uENTER\n Activates selected keyword, changing the current window. \uESC\n Terminates the work with the Help-Engine. \uUsing keyboard\n To scroll the actual window, you can use the \uPgUp\n / \uPgDn\n keys, as well as the direction keys (\u \n and \u \n). With \uHome\n you can go back to the top of the current help text, with \uEnd\n you jump to the end of the text. Please note that scrolling is only avaliable if the current help text is longer as 18 lines of text. This can be controlled by the slider \n" at the right border of the window: Only if the slider is present in the scroll bar, scrolling will be possible. You may note that some words are marked \vlike this\v16.. Those words are special terms, which are explained nearer in another help text. To go to this specific help text, simply select the word, pressing the \uTab\n key. If there are more than one keywords present, for each time you press the \uTab\n key, the cursor will move one keyword forward. If you press \uShift-Tab\n, the cursor will move one keyword backwards. Press \uEnter\n to activate the selec- ted keyword. If you wish to go to the opening screen, press \uF1\n. To return to the previous help text, you should press \uAlt-F1\n. To finish the work, simply press \uEsc\n. \uUsing mouse\n To scroll the window, you can place the mouse cursor at the scroll bar, and press a mouse button. The program will try to place the slider at the current mouse cursor position. If the help text is very short, the screen may flicker, showing two pages of the current help alternatly. You can use the same buttons at the bottom of the window, placing the cursor over the buttons and pressing a mouse button. If you press the left mouse button over the word \u \n, you will move the selection cursor one keyword forward, pressing the right mouse button instead, you will move backwards. You can also activate the keywords directly with the mouse: you have only to move the mouse cursor over the word and press a button. The word will be selected and activated when releasing the mouse button. \uNote\n Sometimes the buttons are shown "dimmed" in the button bar. This may occour when the button may not be activated at this moment. \uThis is only a test.\n The text you activated does not have any special meaning. Please use \uAlt-F1\n to return to the previous help text, or \uEsc\n to abort. You may want to return \vto the previous help text\v15. now. \u- A -\n \vAbnormal task\v913. \vAbort statement\v913. \vAbs unary operator\v417. \vAbsolute value operation\v417. \vAccept alternative (of a selective wait)\v908. \vAccept statement\v905. \vAccess to external files\v1402. \vAccess type\v330. \vAccess type definition\v330. \vAccuracy of a numeric operation\v418. \vAccuracy of a numeric operation of a universal type\v423. \vActual parameter\v607. \vActual parameter part\v606. \vAddition operation\v414. \vAddition accuracy for a real type\v418. \vADDRESS (predefined attribute)\v1310. \vAddress clause\v1305. \vAFT (predefined attribute) for a fixed point\v320. \vAft field of text_io input or output\v1416. \vAggregate\v407. \vAlignment clause (in a record representation clause)\v1304. \vAll in a selected component\v404. \vAllocation of processing resources\v911. \vAllocator\v421. \vAllowed\v108. \vAncestor library unit\v1004. \vAnonymous type\v306. \vANSI (american national standards institute)\v201. \vApostrophe character\v201. \vin a character literal\v207. \vdelimiter\v202. \vin an attribute\v405. \vof a qualified expression\v420. \vApply\v1002. \vAppropriate for a type\v401. \vfor an array type\v402. \vfor a record type\v404. \vfor a task type\v404. \vprefix of an attribute\v405. \vArbitrary selection of select alternatives\v908. \vArgument association in a pragma\v210. \vArgument identifier in a pragma\v210. \vArithmetic operator\v411. \vArray aggregate\v409. \vArray assignment\v503. \vArray type\v321. \vArray type definition\v321. \vArrow compound delimiter\v202. \vASCII (american standard code for information interchange)\v201. \vASCII (predefined library package)\v312. \vAssignment compound delimiter\v202. \vin an object declaration\v303. \vAssignment operation\v502. \vAssignment statement\v502. \vAssociated declarative region of a declaration or statement\v801. \vAttribute\v405. \vAttribute designator\v405. \u- B -\n \vBASE (predefined attribute)\v308. \vfor an access type\v332. \vfor an array type\v323. \vfor a discrete type\v315. \vfor a fixed point type\v320. \vfor a floating point type\v318. \vfor a private type\v706. \vfor a record type\v708. \vBase type (of a subtype)\v305. \vas a static subtype\v422. \vas target type of a conversion\v419. \vdue to elaboration of a type definition\v306. \vof an array type 3.6;\v403. \vof a derived subtype\v309. \vof a discriminant determining the set of choices of a variant part\v328. \vof a fixed point type\v319. \vof a floating point type\v317. \vof a formal parameter of a generic formal subprogram\v1204. \vof an integer type\v314. \vof a parent subtype\v309. \vof a qualified expression\v420. \vof a type mark\v307. \vof a type mark in a membership test\v413. \vof the discrete range in a loop parameter specification\v506. \vof the expression in a case statement\v505. \vof the result of a generic formal function\v1204. \vof the result subtype of a function\v509. \vof the subtype indication in an access type definition\v330. \vof the type in the declaration of a generic formal object\v1202. \vof the type mark in a renaming declaration\v805. \vBased literal\v206. \vas a numeric literal\v204. \vBasic character\v201. \vBasic character set\v201. \vis sufficient for a program text\v212. \vBasic declaration\v301. \vas a basic declarative item\v333. \vBasic declarative item\v333. \vin a package specification\v701. \vBasic graphic character\v201. \vBasic operation\v308. \vaccuracy for a real type\v418. \vimplicitly declared\v301. \vof an access type\v332. \vof an array type\v323. \vof a derived type\v309. \vof a discrete type\v315. \vof a fixed point type\v320. \vof a floating point type\v318. \vof a limited type\v708. \vof a private type\v706. \vof a record type\v329. \vof a task type\v912. \vpropagating an exception\v1108. \vraising an exception\v1105. \vwhich is an attribute\v405. \uBelong\n \vto a range\v310. \vto a subtype\v305. \vto a subtype of an access type\v330. \vBinary adding operator\v411. \vfor time predefined type\v906. \vin a simple expression\v410. \voverloaded\v611. \vBinary operation\v411. \vBlank skipped by a text_io procedure\v1413. \vBlock name\v507. \vdeclaration\v501. \vimplicitly declared\v301. \vBlock statement\v507. \vas a compound statement\v501. \vas a declarative region\v801. \ventity denoted by an expanded name\v404. \vhaving dependent tasks\v904. \vincluding an exception handler\v1102. \vincluding an implicit declaration\v501. \vincluding a suppress pragma\v1109. \vraising an exception\v1105. \vBody\v333. \vas a later declarative item\v333. \vBody stub\v1004. \vacting as a subprogram declaration\v603. \vas a body\v333. \vas a portion of a declarative region\v801. \vmust be in the same declarative part as the declaration\v333. \vBOOLEAN (predefined type)\v313. \vderived\v309. \vresult of a condition\v504. \vresult of an explicitly declared equality operator\v611. \vBoolean type\v313. \voperaion\v315. \voperation comparing real operands\v418. \vBound of an array\v321. \vaggregate\v409. \vignored due to index_check suppression\v1109. \vinitialization in an allocator constrains the allocated object\v421. \vresult of an operation\v412. \vBound of a range\v310. \vof a discrete range in a slice\v403. \vof a discrete range is of universal_integer type\v322. \vof a static discrete range\v422. \vBound of a scalar type\v310. \vBound of a slice\v403. \vBox compound delimiter\v202. \vin a generic parameter declaration\v1201. \vin an index subtype definition\v321. \u- C -\n \vCALENDAR (predefined library package)\v906. \uCALLABLE (predefined attribute)\n \vfor an abnormal task\v913. \vfor a task object\v912. \vCalling conventions of another language system\v1313. \vCancelation of an entry call statement\v909. \vCarriage return format effector\v201. \vCase statement\v505. \vas a compound statement\v501. \vCase statement alternative\v505. \vCatenation operation\v414. \vfor an array type\v323. \vin a replacement of a string literal\v212. \vCatenation operator\v411. \vCharacter\v201. \vin a lexical element\v200. \vnames of characters\v201. \vreplacement in program text\v212. \vCHARACTER (predefined type)\v312. \vas the component type of the string type\v324. \vCharacter literal\v207. \vas a basic operation\v308. \vas an enumeration literal\v311. \vas a name\v401. \vas a selector\v404. \vdeclared by an enumeration literal specification\v301. \vin a static expression\v422. \vin homograph declarations\v803. \vmust be visible at the place of a string literal\v406. \vCharacter types\v312. \voperation\v315. \vsubject to an attribute\v315. \vChoice\v328. \vin an aggregate\v407. \vin an array aggregate\v409. \vin a case statement alternative\v505. \vin a component association\v407. \vin a record aggregate\v408. \vin a variant of a record type definition\v328. \vCircularity in dependencies between compilation units\v1008. \vClass of type\v305. \vof a derived type\v309. \vCLOCK (predefined function)\v906. \uCLOSE (input-output procedure)\n \vin an instance of direct_io\v1403. \vin an instance of sequential_io\v1403. \vin text_io\v1403. \vClosed alternative (of a selective wait)\v908. \vClosed file\v1401. \vCode statement\v1312. \vas a simple statement\v501. \vCOL (text_io function)\v1412. \vraising an exception\v1419. \vCollection (of an access type)\v330. \vof a derived access type\v1302. \vColon character\v201. \vreplacing sharp character\v212. \vColon delimiter\v202. \vColumn\v1412. \uComma\n \vcharacter\v201. \vdelimiter\v202. \vComment\v209. \vin a conforming construct\v604. \vCommunication of values between tasks\v905. \vCompatibility (of constraints)\v307. \vfailure not causing constraint_error\v1109. \vof a discrete range with an index subtype\v322. \vof discriminant constraints\v327. \vof fixed point constraints\v319. \vof floating point constraints\v317. \vof index constraints\v322. \vof range constraints\v310. \vCompilation\v1001. \vas a sequence of lexical elements\v200. \vincluding an inline pragma\v605. \vCompilation unit\v1001. \vcompiled after library units named in its context clause\v1006. \vfollowed by an inline pragma\v605. \vwith a context clause\v1002. \vwith a use clause\v804. \vCompile time evaluation of expressions\v1009. \vCompiler\v1007. \vCompleted block statement\v904. \vCompleted subprogram\v904. \vCompleted task\v904. \vas recipient of an entry call\v905. \vbecoming abnormal\v913. \vcompletion during activation\v903. \vdue to an exception in the task body\v1105. \vComponent (of a composite type)\v305. \vcombined by aggregate\v407. \vdepending on a discriminant\v326. \vname starting with a prefix\v401. \vof an array\v321. \vof a constant\v303. \vof a derived type\v309. \vof an object\v302. \vof a private type\v706. \vof a record\v325. \vof a variable\v303. \vsimple name as a choice\v328. \vsubtype\v325. \vsubtype itself a composite type\v322. \vthat is a task object\v903. \vwhose type is a limited type\v708. \vComponent association\v407. \vin an aggregate\v407. \vincluding an expression which is an array aggregate\v409. \vnamed component association\v407. \vnamed component association for selective visibility\v803. \vpositional component association\v407. \vComponent clause (in a record representation clause)\v1304. \vComponent declaration\v325. \vas part of a basic declaration\v301. \vhaving an extended scope\v802. \vin a component list\v325. \vof an array object\v322. \vof a record object\v327. \vvisibility\v803. \vComponent list\v325. \vin a record type definition\v325. \vin a variant\v328. \vComponent subtype definition\v325. \vin a component declaration\v325. Component type \vcatenation with an array type\v414. object initialization [see: initial value] \vof an expression in an array aggregate\v409. \vof an expression in a record aggregate\v408. \vof a generic formal array type\v1210. \voperation determining a composite type operation\v412. \vComposite type\v305. \vincluding a limited subcomponent\v708. \vincluding a task subcomponent\v902. \vobject initialization\v303. \vof an aggregate\v407. \vwith a private type component\v706. \vCompound delimiter\v202. \vnames of delimiters\v202. \vCompound statement\v501. \vincluding the destination of a goto statement\v510. \vCondition\v504. \vdetermining an open alternative of a selective wait\v908. \vin an exit statement\v508. \vin an if statement\v504. \vin a while iteration scheme\v506. \vConditional compilation\v1009. \vConditional entry call\v909. \vand renamed entries\v805. \vsubject to an address clause\v1306. \vConforming\v604. \vdiscriminant parts\v604. \vformal parts\v604. \vformal parts in entry declarations and accept statements\v905. \vsubprogram specifications\v604. \vsubprogram specifications in body stub and subunit\v1004. \vtype marks\v604. \vConstant\v303. \vaccess object\v330. \vformal parameter\v602. \vin a static expression\v422. \vrenamed\v805. \vthat is a slice\v403. \vConstant declaration\v303. \vas a full declaration\v707. \vwith an array type\v322. \vwith a record type\v327. CONSTRAINED (predefined attribute) \vfor an object of a type with discriminants\v329. \vfor a private type\v706. \vConstrained array definition\v321. \vin an object declaration\v302. \vConstrained array type\v321. \vConstrained subtype\v305. \vdue to elaboration of a type definition\v306. \vdue to the elaboration of a derived type definition\v309. \vobject declarations\v303. \vof a subtype indication in an allocator\v421. \vConstraint (on an object of a type)\v305. \vexplicitly specified by use of a qualification\v420. \vin a subtype indication in an allocator\v421. \vnot considered in overload resolution\v807. \von a derived subtype\v309. \von a formal parameter\v602. \von a formal parameter of a generic formal subprogram\v1204. \von a generic actual parameter\v1207. \von a generic formal object\v1202. \von a generic formal parameter\v1201. \von an object designated by an access value\v330. \von a renamed object\v805. \von a subcomponent subject to a component clause must be static\v1304. \von a subtype of a generic formal type\v1203. \von a type mark in a generic parameter declaration\v1207. \von a variable\v303. \von the result of a generic formal function\v1204. \vCONSTRAINT_ERROR (predefined exception)\v1101. \vraised by an accept statement\v905. \vraised by an actual parameter not in the subtype of the formal\v607. \vparameter\v607. \vraised by an allocator\v421. \vraised by an assignment\v502. \vraised by an attribute\v315. \vraised by a component of an array aggregate\v409. \vraised by a component of a record aggregate\v408. \vraised by an entry call statement\v905. \vraised by a formal parameter not in the subtype of the actual\v607. \vparameter\v607. \vraised by an index value out of bounds\v402. \vraised by a logical operation on arrays of different lengths\v412. \vraised by a name with a prefix evaluated to a null access value\v401. \vraised by a qualification\v420. \vraised by a result of a conversion\v419. \vraised by a return statement\v509. \vraised by incompatible constraints\v307. \vraised by integer exponentiation with a negative exponent\v417. \vraised by matching failure in an array assignment\v503. \vraised by naming of a variant not present in a record\v404. \vraised by the elaboration of a generic instantiation\v1207. \vraised by the initialization of an object\v303. \vraised by the result of catenation\v414. \vContext clause\v1002. \vdetermining order of elaboration of compilation units\v1008. \vin a compilation unit\v1001. \vincluding a use clause\v804. \vinserted by the environment\v1007. \vof a subunit\v1004. \vContext of overload resolution\v807. \vCONTROLLED (predefined pragma)\v421. \vConversion operation\v419. \vapplied to an undefined value\v303. \vas a basic operation\v308. \vbetween array types\v419. \vbetween numeric types\v308. \vfrom universal_ fixed type\v416. \vin a static expression\v422. \vof a universal type expression\v502. \vof the bounds of a loop parameter\v506. \vto a derived type\v309. \vto a real type\v418. \vConvertible universal operand\v419. \vCopy parameter passing\v602. \vCOUNT (predefined attribute) for an entry\v912. \vCOUNT (predefined integer type)\v1402. CREATE (input-output procedure) \vin an instance of direct_io\v1403. \vin an instance of sequential_io\v1403. \vin text_io\v1403. \vraising an exception\v1419. \vCurrent column number\v1408. \vCurrent index of a direct access file\v1402. \vCurrent line number\v1408. \vCurrent mode of a file\v1401. \vCurrent page number\v1408. \vCurrent size of a direct access file\v1402. \vCURRENT_INPUT (text_io function)\v1410. \vCURRENT_OUTPUT (text_io function)\v1410. \u- D -\n \vDATA_ERROR (input-output exception)\v1419. \vDAY (predefined function)\v906. \vDecimal literal\v205. \vas a numeric literal\v204. \vDecimal number text_io\v1415. \vDeclaration\v301. \vas an overload resolution context\v807. \vdetermined by visibility from an identifier\v803. \vmade directly visible by a use clause\v804. \vof an enumeration literal\v311. \vof a formal parameter\v601. \vof a loop parameter\v506. \voverloaded\v610. \vraising an exception\v1106. \vto which a representation clause applies\v1301. \vDeclarative item\v333. \vin a code procedure body\v1312. \vin a declarative part\v333. \vin a package specification\v605. \vin a visible part\v704. \vwhich is a use clause\v804. \vDeclarative part\v333. \vin a block statement\v507. \vin a package body\v701. \vin a subprogram body\v603. \vin a task body\v901. \vincluding a generic declaration\v1205. \vincluding an inline pragma\v605. \vincluding an interface pragma\1313. \vincluding a representation clause\v1301. \vincluding a suppress pragma\v1109. \vincluding a task declaration\v903. \vwith implicit declarations\v501. \vDeclarative region\v801. \vdetermining the visibility of a declaration\v803. \vformed by the predefined package standard\v806. \vin which a declaration is hidden\v803. \vincluding a full type definition\v706. \vincluding a subprogram declaration\v603. \vDefault determination of a representation for an entity\v1301. \uDefault expression\n \vcannot include a forcing occurrence\v1301. \vfor a component\v305. \vfor a component of a derived type object\v309. \vfor a discriminant\v326. \vfor a formal parameter\v601. \vfor a formal parameter of a generic formal subprogram\v1201. \vfor a formal parameter of a renamed subprogram or entry\v805. \vfor a generic formal object\v1201. \vfor the discriminants of an allocated object\v421. \vin a component declaration\v325. \vin a discriminant specification\v326. \vincluding the name of a private type\v326. \vDefault file\v1410. \vDefault generic formal subprogram\v1201. \vDefault initial value (of a type)\v305. \vfor an access type object\v330. \vfor a record type object\v325. \vDefault initialization (for an object)\v303. \vDefault mode (of a file)\v1403. \uDefault_aft (fiels length)\n \vof fixed_io or float_io\v1416. \uDefault_base\n \vof integer_io\v1415. \uDefault-exp (field length)\n \vof fixed_io or float_io\v1415. \uDefault_fore (field length)\n \vof fixed_io or float_io\v1418. \uDefault_setting (letter case)\n \vof enumeration_io\v1417. \uDefault_width (field length)\n \vof enumeration_io\v1417. \vof integer_io\v1415. \vDeferred constant\v707. \vof a limited type\v708. \vDeferred constant declaration\v704. \vas a basic declaration\v301. \vcannot include a forcing occurrence\v1301. \vDelay alternative (of a selective wait)\v908. \vDelay expression\v906. \vin a timed entry call\v910. \vDelay statement\v906. \vas a simple statement\v501. \vin an abnormal task\v913. \vin a select alternative\v908. \vin a timed entry call\v910. \uDELETE (input-output procedure)\n \vin an instance of direct_io\v1403. \vin an instance of sequential_io\v1403. \vin text_io\v1403. \vDelimiter\v202. \vDelta (of a fixed point type)\v319. \vof universal_fixed\v416. \vDELTA (predefined attribute)\v320. \vDenote an entity\v301. \vDependence between compilation units\v1006. \vcircularity implying illegality\v1008. \vDependence on a discriminant\v326. \vaffecting renaming\v805. \vby a subcomponent which is an actual parameter\v602. \veffect on compatibility\v327. \veffect on matching of components\v413. \vfor an assignment\v502. \vDependent task\v904. \vdelaying exception propagation\v1105. \vof an abnormal task\v913. \uDerivable subprogram\n \vprohibiting representation clauses\v1301. \uDerived subprogram\n \vas an operation\v308. \vimplicitly declared\v308. \vDerived type\v309. \vconversion to or from a parent type or related type\v419. \vof an access type designating a task type determining task\v904. \vdependence\v904. \vof a boolean type\v309. \vof a limited type\v708. \vof a private type\v705. \vsubject to a representation clause\v1301. \vDerived type definition\v309. \vDesignate\v330. \vDesignated subtype (of an access type)\v330. \vDesignated type (of an access type)\v330. \vDesignator (of a function)\v601. \vin a function declaration\v411. \vin a subprogram body\v603. \vin a subprogram specification\v601. \vof a generic formal subprogram\v1212. \vof a library unit\v1001. \voverloaded\v610. \vDEVICE_ERROR (input-output exception)\v1419. \vDigit\v201. \vin a based literal\v206. \vin a decimal literal\v205. \vin an identifier\v203. \vDigits (of a floating point type)\v317. \vDIGITS (predefined attribute)\v318. \vDimensionality of an array\v321. \vDirect access file\v1402. \vDirect input-output\v1406. \vDirect visibility\v803. \vdue to a use clause\v804. \vof a library unit due to a with clause\v1002. \vwithin a subunit\v1004. \vDIRECT_IO (predefined input-output generic package)\v1402. \vexceptions\v1419. \vspecification\v1407. \vDiscrete range\v321. \vas a choice\v328. \vas a choice in an aggregate\v407. \vfor a loop parameter\v506. \vin a choice in a case statement\v505. \vin a generic formal array type declaration\v1203. \vin an index constraint\v321. \vin a loop parameter specification\v506. \vin a slice\v403. \vof entry indices in an entry declaration\v905. \vDiscrete type\v310. \vas a generic actual parameter\v1209. \vas a generic formal type\v1203. \vexpression in a case statement\v505. \vof a discriminant\v326. \vof a loop parameter\v506. \vof index values of an array\v321. \voperation\v315. \vDiscriminant\v305. \vin a record aggregate\v408. \vinitialization in an allocator constrains the allocated object\v421. \vof a formal parameter\v602. \vof a generic actual type\v1208. \vof a generic formal type\v1206. \vof an implicitly initialized object\v303. \vof an object designated by an access value\v327. \vof a private type\v706. \vof a variant part must not be of a generic formal type\v328. \vsimple name in a variant part\v328. \vsubcomponent of an object\v303. \vwith a default expression\v326. \vDiscriminant association\v327. \vin a discriminant constraint\v327. \vnamed discriminant association\v327. \vnamed discriminant association for selective visibility\v803. \vpositional discriminant association\v327. \vDiscriminant constraint\v327. \vignored due to access_check suppression\v1109. \vin an allocator\v421. \von an access type\v330. \vviolated\v1101. \vDiscriminant part\v326. \vabsent from a record type declaration\v325. \vas a portion of a declarative region\v801. \vconforming to another\v801. \vin a generic formal type declaration\v326. \vin an incomplete type declaration\v331. \vin a private type declaration\v704. \vin a type declaration\v305. \vmay not include a pragma\v210. \vof a full type declaration is not elaborated\v306. \vDiscriminant specification\v326. \vas part of a basic declaration\v301. \vdeclaring a component\v325. \vhaving an extended scope\v802. \vin a discriminant part\v326. \vvisibility\v803. \uDivide\n \vcharacter\v201. \vdelimiter\v202. \vDivision operation\v416. \vaccuracy for a real type\v418. \uDot\n \vcharacter\v201. \vdelimiter\v202. \vdelimiter of a selected component\v803. \vDouble dot compound delimiter\v202. \vDouble hyphen starting a comment\v209. \vDouble star compound delimiter\v202. \vDURATION (predefined type)\v906. \vof alternative delay statements\v908. \u- E -\n \vELABORATE (predefined pragma)\v1008. \vElaborated\v333. \vElaboration\v333. \voptimized\v1009. \vElaboration has no other effect\v301. \uElaboration of\n \van access type definition\v330. \van array type definition\v321. \va body stub\v1004. \va component declaration\v325. \va component subtype definition\v325. \va constrained array definition\v321. \va declaration\v301. \va declarative item\v333. \va declarative part\v333. \va deferred constant declaration\v707. \va derived type definition\v309. \va discriminant constraint\v327. \va discriminant part\v326. \va discriminant specification\v326. \van entry declaration\v905. \van enumeration literal specification\v311. \van enumeration type definition\v311. \va fixed point type declaration\v319. \va floating point type declaration\v317. \va formal part\v601. \va full type declaration\v306. \va generic body\v1205. \va generic declaration\v1201. \va generic instantiation\v1206. \van incomplete type declaration\v331. \van index constraint\v322. \van integer type definition\v314. \va library unit\v1008. \va loop parameter specification\v506. \van object declaration\v303. \va package body\v703. \va package declaration\v702. \va parameter specification\v601. \va private type declaration\v705. \va range constraint\v310. \va real type definition\v316. \va record type definition\v325. \va renaming declaration\v805. \va representation clause\v1301. \va subprogram body\v603. \va subprogram declaration\v601. \va subtype declaration\v307. \va subtype indication\v307. \va task body\v901. \va task declaration\v901. \va task specification\v901. \va type declaration\v306. \va type definition \v306. \van unconstrained array definition\v321. \va use clause\v804. \vElement in a file\v1400. \vin a direct access file\v1406. \vin a sequential access file\v1404. \vELEMENT_TYPE (generic formal type of direct_io)\v1407. \vELEMENT_TYPE (generic formal type of sequential_io)\v1405. \uElse part\n \vof a conditional entry call\v909. \vof an if statement\v504. \vof a selective wait\v908. \vEMAX (predefined attribute)\v318. \vEmpty string literal\v208. \vEnd of line\v202. \vas a separator\v202. \vdue to a format effector\v202. \vterminating a comment\v209. \vEND_ERROR (input-output exception)\v1419. END_OF_FILE (input-output function) \vin an instance of direct_io\v1402. \vin an instance of sequential_io\v1404. \vin text_io\v1409. \vEND_OF_LINE (text_io function)\v1412. \vraising an exception\v1419. \vEND_OF_PAGE (text_io function)\v1412. \vEntry (of a task)\v905. \vdeclared by instantiation of a generic formal parameter\v1206. \vdenoted by an indexed component\v402. \vdenoted by a selected component\v404. \vname starting with a prefix\v401. \vof a derived task type\v309. \vof a task designated by an object of a task type\v905. \vrenamed\v805. \vsubject to an address clause\v1305. \vsubject to a representation clause\v1301. \vEntry call\v905. \vto an abnormal task\v905. \vto communicate values\v914. \vEntry call statement\v905. \vas a simple statement\v501. \vin an abnormal task\v913. \vin a conditional entry call\v909. \vin a timed entry call\v910. \vEntry declaration\v905. \vas an overloaded declaration\v803. \vas part of a basic declaration\v301. \vcannot include a forcing occurrence\v1301. \vhaving an extended scope\v802. \vin a task specification\v901. \vincluding the name of a private type\v705. \vvisibility\v803. \vEntry family\v905. \vdenoted by a selected component\v404. \vname starting with a prefix\v401. \vEntry index (in the name of an entry of a family)\v905. \vfor an open accept alternative\v908. \vin a conditional entry call\v909. \vin a timed entry call\v910. \vEntry queue (of calls awaiting acceptance)\v905. \vcount of calls in the queue\v909. \vdue to queued interrupts\v1306. \vof an abnormal task\v913. \vEnumeration literal\v311. \vas an operation\v308. \vas an operator\v315. \vas result for image attribute\v315. \vas the parameter for value attribute\v315. \vimplicitly declared\v308. \vin a static expression\v422. \vin pragma system_name\v1308. \vof a derived type\v309. \voverloaded\v803. \vrenamed as a function\v805. \vrepresentation\v1303. \vEnumeration literal specification\v311. \vas part of a basic declaration\v301. \vmade directly visible by a use clause\v804. \vEnumeration representation clause\v1303. \vas a representation clause\v1301. \vEnumeration type\v311. \vas a character type\v312. \vas a generic formal type\v1203. \vas a generic parameter\v1209. \vboolean\v313. \voperation\v315. \vsubject to an attribute\v315. \vEnumeration type definition\v311. \vENUMERATION_IO (text_io inner generic package)\v1417. \vEnvironment of a program\v1007. \venvironment task calling the main program\v1001. \vEPSILON (predefined attribute)\v318. \uEqual\n \vcharacter\v201. \vdelimiter\v202. \vEquality operator\v411. \vexplicitly declared\v413. \vfor an access type\v332. \vfor an array type\v323. \vfor a generic formal type\v1203. \vfor a limited type\v413. \vfor a real type\v418. \vfor a record type\v329. \vErroneous execution\v108. \vdue to an access to a deallocated object\v1315. \vdue to an unchecked conversion violating properties of objects of the\v1316. \vresult type\v1316. \vdue to assignment to a shared variable\v914. \vdue to changing of a discriminant value\v502. \vdue to independence on parameter-passing mechanism\v602. \vdue to multiple address clauses for overlaid entities\v1305. \vdue to suppression of an exception check\v1109. \vdue to use of an undefined value\v303. \vError bounds of a predefined operation of a real type\v319. \uError detected at\n \vcompilation time\v108. \vrun time\v108. \vError situation\v108. \vError that may not be detected\v108. \vEvaluation (of an expression)\v411. \vat compile time\v422. \vof an actual parameter\v607. \vof an aggregate\v407. \vof an allocator\v421. \vof an array aggregate\v409. \vof a condition\v504. \vof a default expression\v327. \vof a default expression for a formal parameter\v608. \vof a discrete range\v310. \vof a discrete range used in an index constraint\v322. \vof an entry index\v905. \vof an expression in an assignment statement\v502. \vof an expression in a constraint\v307. \vof an expression in a generic actual parameter\v1206. \vof an indexed component\v402. \vof a literal\v406. \vof a logical operation\v412. \vof a name\v401. \vof a name in an abort statement\v913. \vof a name in a renaming declaration\v805. \vof a name of a variable\v502. \vof a primary\v410. \vof a qualified expression\v420. \vof a range\v310. \vof a record aggregate\v408. \vof a short circuit control form\v412. \vof a static expresion\v422. \vof a type conversion\v419. \vof a universal expression\v423. \vof the bounds of a loop parameter\v506. \vof the conditions of a selective wait\v908. \vException\v1100. \vas an entity\v301. \vcausing a loop to be exited\v506. \vcausing a transfer of control\v501. \vdue to an expression evaluated at compile time\v1009. \vimplicitly declared in a generic instantiation\v1101. \vin input-output\v1419. \vrenamed\v805. \vsuppress pragma\v1109. \vELABORATE (predefined pragma)\v1008. \vException choice\v1102. \vException declaration\v1101. \vas a basic declaration\v301. \vException handler\v1102. \vin an abnormal task\v913. \vin a block statement\v507. \vin a package body\v701. \vin a subprogram body\v603. \vin a task body\v901. \vincluding a raise statement\v1103. \vincluding the destination of a goto statement\v510. \vincluding the name of an exception\v1101. \vnot allowed in a code procedure body\v1312. \vraising an exception\v1105. \vselected to handle an exception\v1105. \vException handling\v1104. \vException propagation\v1100. \vdelayed by a dependent task\v1105. \vfrom a declaration\v1106. \vfrom a predefined operation\v1108. \vfrom a statement\v1105. \vto a communicating task\v1107. Exception raised during execution or elaboration of \van accept statement\v1107. \van allocator of a task\v903. \va conditional entry\v909. \va declaration\v1106. \va declarative part that declares tasks\v903. \va generic instantiation\v1207. \va selective wait\v908. \va subprogram call\v603. \va statement\v1105. \va subprogram call\v603. \va task\v1107. \vtask activation\v903. \va timed entry call\v910. \vExceptions and optimization\v1108. \vExclamation character\v201. \vreplacing vertical bar\v212. \vExit statement\v508. \vas a simple statement\v501. \vcausing a loop to be exited\v506. \vcausing a transfer of control\v501. \vcompleting block statement execution\v904. \vExpanded name\v404. \vdenoting a loop\v506. \vin a static expression\v422. \vof a parent unit\v1004. \vreplacing a simple name\v604. \vExplicit conversion\v419. type conversion] \vfrom universal_fixed type\v416. \vto a real type\v418. \vExplicit declaration\v301. \vExponent of a floating point number\v317. \uExponent part\n \vin output of real values\v1416. \vof a based literal\v205. \vof a decimal literal\v205. \vExponentiating operator\v411. \vin a factor\v410. \voverloaded\v611. \vExponentiation compound delimiter\v202. \vExponentiation operation\v417. \vExpression\v410. \vas an actual parameter\v606. \vas a condition\v504. \vas a generic actual parameter\v1206. \vas the argument of a pragma\v210. \vin an actual parameter of a conditional entry call\v909. \vin an actual parameter of an entry call statement\v905. \vin an actual parameter of a timed entry call\v910. \vin an allocator\v421. \vin an assignment statement\v502. \vin an attribute designator\v405. \vin a case statement\v505. \vin a choice in a case statement\v505. \vin a component association\v407. \vin a component declaration\v325. \vin a constraint\v307. \vin a conversion\v419. \vin a discriminant association\v327. \vin a discriminant specification\v326. \vin a generic formal part\v1201. \vin an indexed component\v402. \vin a length clause\v1302. \vin a name of a variable\v502. \vin a number declaration\v302. \vin an object declaration\v302. \vin a parameter specification\v601. \vin a primary\v410. \vin a qualified expression\v420. \vin a representation clause\v1301. \vin a return statement\v509. \vin a specification of a derived subprogram\v309. \vin a type conversion\v807. \vincluding the name of a private type\v705. \vspecifying an entry in a family\v402. \vspecifying the value of an index\v402. \vwith a boolean result\v412. \vExtended_digit in a based literal\v206. \vExternal file\v1401. \u- F -\n \vFactor\v410. \vin a term\v410. \vFALSE boolean enumeration literal\v313. \vFIELD (predefined integer subtype)\v1413. \vFile (object of a file type)\v1401. \vFile management\v1403. \vin text_io\v1409. \vFile terminator\v1408. \uFILE_MODE (input-output type)\n \vin an instance of direct_io\v1401. \vin an instance of sequential_io\v1401. \vin text_io\v1401. \uFILE_TYPE (input-output type)\n \vin an instance of direct_io\v1401. \vin an instance of sequential_io\v1401. \vin text_io\v1401. \vFIRST (predefined attribute)\v1500. \vfor an access value\v332. \vfor an array type\v323. \vfor a scalar type\v310. \vFirst named subtype\v1301. \vFIRST_BIT (predefined attribute)\v1310. \vFixed accuracy definition\v319. \vFixed point constraint\v319. \von a derived subtype\v309. \vFixed point predefined types\v319. \vFixed point types\v319. \vaccuracy of an operation\v418. \vas a generic actual type\v1209. \vas a generic formal type\v1203. \verror bounds\v418. \voperation\v320. \vresult of an operation out of range of the type\v418. \vFIXED_IO (text_io inner generic package)\v1416. \vFLOAT (predefined type)\v317. \vFLOAT_IO (text_io inner generic package)\v1416. \vFloating accuracy definition\v317. \vFloating point constraint\v317. \von a derived subtype\v309. \vFloating point types\v317. \vaccuracy of an operation\v418. \vas a generic actual type\v1209. \vas a generic formal type\v1203. \verror bounds\v418. \voperation\v318. \vresult of an operation out of range of the type\v418. \vFont design of graphical symbols\v201. \vForcing occurrence (of a name leading to default determination of\v1301. \vrepresentation)\v1301. \vFORE (predefined attribute) for a fixed point type\v320. \vFore field of text_io input or output\v1416. \uFORM (input-output function)\n \vin an instance of direct_io\v1403. \vin an instance of sequential_io\v1403. \vin text_io\v1403. \vraising an exception\v1419. \vForm feed format effector\v201. \vForm string of a file\v1401. \vFormal parameter\v601. \v(of an entry)\v905. \v(of a function)\v609. \v(of an operator)\v611. \v(of a subprogram)\v601. \vas a constant\v303. \vas an object\v302. \vas a variable\v303. \vnames and overload resolution\v610. \vnames and overload resolution\v610. \vof a derived subprogram\v309. \vof a generic formal subprogram\v1201. \vof a main program\v1001. \vof an operation\v308. \vof a renamed entry or subprogram\v805. \vwhich is of an array type\v322. \vwhich is of a limited type\v708. \vwhich is of a record type\v327. \vwhich is of a task type\v902. \vFormal part\v601. \vconforming to another\v604. \vin an accept statement\v905. \vin an entry declaration\v905. \vin a subprogram specification\v601. \vmust not include a pragma\v210. \vFormat effector\v201. \vas a separator\v202. \vin an end of line\v202. \vFormat of text_io input or output\v1413. \vFrame\v1102. \vand optimization\v1108. \vin which an exception is raised\v1105. \uFull declaration\n \vof a deferred constant\v707. \vFull type declaration\v306. \vdiscriminant part is not elaborated\v306. \vof an incomplete type\v331. \vof a limited private type\v708. \vof a private type\v705. \vFunction\v601. \vas a main program\v1001. \vrenamed\v805. \vthat is an attribute\v405. \vFunction call\v606. \vas a prefix\v401. \vas a primary\v410. \vin a static expression\v422. \vwith a parameter of a derived type\v309. \vwith a result of a derived type\v309. \u- G -\n \vGarbage collection\v421. \vGeneric actual object\v1207. \vGeneric actual parameter\v1206. \vcannot be a universal_fixed operation\v416. \vfor a generic formal access type\v1211. \vfor a generic formal array type\v1210. \vfor a generic formal object\v1202. \vfor a generic formal private type\v1208. \vfor a generic formal scalar type\v1209. \vfor a generic formal subprogram\v1204. \vfor a generic formal type\v1203. \vis not static\v422. \vthat is an array aggregate\v409. \vthat is a loop parameter\v506. \vthat is a task type\v902. \vGeneric actual part\v1206. \vGeneric actual subprogram\v1204. \uGeneric actual type\n \vfor a generic formal access type\v1211. \vfor a generic formal array type\v1210. \vfor a generic formal scalar type\v1209. \vfor a generic formal type with discriminants\v1208. \vfor a generic private formal type\v1208. \vthat is a private type\v705. \vGeneric association\v1206. \vnamed generic association\v1206. \vnamed generic association for selective visibility\v803. \vpositional generic association\v1206. \vGeneric body\v1205. \vin a package body\v701. \vincluding an exception handler\v1102. \vincluding an exit statement\v508. \vincluding a goto statement\v510. \vincluding an implicit declaration\v501. \vmust be in the same declarative part as the declaration\v333. \vnot yet elaborated at an instantiation\v333. \vGeneric declaration\v1201. \vand body as a declarative region\v801. \vand proper body in the same compilation\v1006. \vas a basic declaration\v301. \vas a later declarative item\v333. \vas a library unit\v1001. \vin a package specification\v701. \vrecompiled\v1006. \vGeneric formal object\v1201. \vof an array type\v322. \vof a record type\v327. \vGeneric formal parameter\v1201. \vas a constant\v303. \vas a variable\v303. \vof a limited type\v708. \vof a task type\v902. \vGeneric formal part\v1201. \vGeneric formal subprogram\v1201. \vformal function\v1204. \vwith the same name as another\v1206. \vGeneric formal type\v1201. \vas index or component type of a generic formal array type\v1210. \vdiscriminant must not be the discriminant of a variant\v328. \vformal access type\v1203. \vformal array type\v1203. \vformal array type (constrained)\v1203. \vformal discrete type\v1203. \vformal enumeration type\v1203. \vformal fixed point type\v1203. \vformal floating point type\v1203. \vformal integer type\v1203. \vformal limited private type\v1203. \vformal limited type\v1203. \vformal part\v1203. \vformal private type\v1203. \vformal private type with discriminants\v1208. \vformal scalar type\v1203. \vGeneric instance\v1206. \vinlined in place of each call\v605. \vof a generic package\v1206. \vof a generic subprogram\v1206. \vraising an exception\v1105. \vGeneric instantiation\v1206. \vas a basic declaration\v301. \vas a later declarative item\v333. \vas a library unit\v1001. \vbefore elaboration of the body\v333. \vimplicitly declaring an exception\v1101. \vinvoking an operation of a generic actual type\v1203. \vof a predefined input-output package\v1401. \vrecompiled\v1006. \vwith a formal access type\v1211. \vwith a formal array type\v1210. \vwith a formal scalar type\v1209. \vwith a formal subprogram\v1212. \vGeneric package\v1201. \vfor input-output\v1400. \vinstantiation\v1206. \vspecification\v1201. \vGeneric package body\v1205. \vGeneric parameter declaration\v1201. \vas a declarative region\v801. \vhaving an extended scope\v802. \vvisibility\v803. \vGeneric specification\v1201. \vGeneric subprogram\v1201. \vbody\v1205. \vinstantiation\v1206. \vinterface pragma is not defined\v1313. \vspecification\v1201. \vGeneric type definition\v1201. \vGeneric unit\v1200. \vincluding an exception declaration\v1101. \vincluding a raise statement\v1103. \vsubject to a suppress pragma\v1109. \vwith a separately compiled body\v1004. \vGET (text_io procedure)\v1413. \vfor character and string types\v1414. \vfor enumeration types\v1417. \vfor integer types\v1417. \vfor real types\v1416. \vraising an exception\v1419. \vGET_LINE (text_io procedure)\v1414. \vGlobal declaration\v801. \vof a variable shared by tasks\v914. \vGoto statement\v510. \vas a simple statement\v501. \vcausing a loop to be exited\v506. \vcausing a transfer of control\v501. \vcompleting block statement execution\v904. \vGraphic character\v201. \vin a character literal\v207. \vin a string literal\v208. \vGraphical symbol\v201. \vnot available\v212. \uGreater than\n \vcharacter\v201. \vdelimiter\v202. \uGreater than or equal\n \vcompound delimiter\v202. \u- H -\n \vHandler\v1192. \vHiding (of a declaration)\v803. \vand renaming\v805. \vand use clauses\v804. \vdue to an implicit declaration\v501. \vof a generic unit\v1201. \vof a library unit\v1001. \vof a subprogram\v610. \vof or by a derived subprogram\v309. \vof the package standard\v1001. \vwithin a subunit\v1004. \vHighest precedence operator\v411. \vas an operation of a discrete type\v315. \vas an operation of a fixed point type\v320. \vas an operation of a floating point type\v318. \voverloaded\v611. \vHomograph declaration\v803. \vand use clauses\v804. \uHorizontal tabulation\n \vas a separator\v202. \vcharacter in a comment\v209. \vformat effector\v201. \vin text_io input\v1413. \vHyphen character\v201. \vstarting a comment\v209. \u- I -\n \vIdentifier\v203. \vand an adjacent separator\v202. \vas an attribute designator\v405. \vas a designator\v601. \vas a reserved word\v211. \vas a simple name\v401. \vcan be written in the basic character set\v212. \vdenoting an object\v303. \vdenoting a value\v304. \vin a deferred constant declaration\v707. \vin an entry declaration\v905. \vin an exception declaration\v1101. \vin a generic instantiation\v1206. \vin an incomplete type declaration\v1312. \vin a number declaration\v304. \vin an object declaration\v302. \vin a package specification\v701. \vin a private type declaration\v704. \vin a renaming declaration\v805. \vin a subprogram specification\v601. \vin a task specification\v901. \vin a type declaration\v306. \vin its own declaration\v803. \vin pragma system_name\v1307. \vof an argument of a pragma\v210. \vof an enumeration value\v311. \vof a formal parameter of a generic formal subprogram\v1204. \vof a generic formal object\v1201. \vof a generic formal subprogram\v1201. \vof a generic formal type\v1201. \vof a generic unit\v1201. \vof a library unit\v1001. \vof a pragma\v210. \vof a subprogram\v601. \vof a subtype\v307. \vof a subunit\v1004. \vof homograph declarations\v803. \voverloaded\v610. \vversus simple name\v310. \vIdentifier list\v302. \vin a component declaration\v325. \vin a deferred constant declaration\v704. \vin a discriminant specification\v326. \vin a generic parameter declaration for generic formal objects\v1201. \vin a number declaration\v302. \vin an object declaration\v302. \vin a parameter specification\v601. \vIdentity operation\v415. \vIf statement\v504. \vas a compound statement\v501. \vIllegal\v108. \vIMAGE (predefined attribute)\v315. \vImmediate scope\v802. \vImplementation defined pragma\v2000. \vImplicit conversion\v419. \vof an integer literal to an integer type\v314. \vof a real literal to a real type\v316. \vof a universal expression\v314. \vof a universal real expression\v418. \vImplicit declaration\v301. \vby a type declaration\v411. \vhidden by an explicit declaration\v803. \vof a basic operation\v301. \vof a block name, loop name, or label\v501. \vof a derived subprogram\v308. \vof an enumeration literal\v308. \vof an equality operator\v611. \vof an exception due to an instantiation\v1101. \vof a library unit\v806. \vof a predefined operator\v411. \vof universal_fixed operators\v416. \uImplicit representation clause\n \vfor a derived type\v309. \vIN_FILE (input-output file_mode enumeration literal)\v1401. \vIncomplete type\v331. \vcorresponding full type declaration\v306. \vIncomplete type declaration\v331. \vas a portion of a declarative region\v801. \vIncorrect order dependence\v108. \vassignment statement\v502. \vbounds of a range constraint\v310. \vcomponent association of an array aggregate\v409. \vcomponent association of a record aggregate\v408. \vcomponent subtype indication\v321. \vdefault expression for a component\v303. \vdefault expression for a discriminant\v303. \vexpression\v411. \vindex constraint\v321. \vlibrary unit\v1008. \vparameter association\v606. \vprefix and discrete range of a slice\v403. \vIndex\v321. \uINDEX (input-output function)\n \vin an instance of direct_io\v1402. \vIndex constraint\v321. \vignored due to index_check suppression\v1109. \vin an allocator\v421. \vin a constrained array definition\v321. \vin a subtype indication\v307. \von an access type\v330. \vviolated\v1101. \vIndex of an element in a direct access file\v1402. \vIndex range\v321. \vmatching\v413. \vIndex subtype\v321. \vIndex subtype definition\v321. \uIndex type\n \vof a choice in an array aggregate\v409. \vof a generic formal array type\v1210. \vIndexed component\v402. \vas a basic operation\v308. \vas a name\v401. \vas the name of an entry\v905. \vof a value of a generic formal array type\v1203. \vInequality compound delimiter\v202. \vInequality operation\v411. \vcannot be explicitly declared\v611. \vfor an access type\v332. \vfor an array type\v323. \vfor a generic formal type\v1203. \vfor a real type\v418. \vfor a real type\v418. \vnot available for a limited type\v708. \vInitial value (of an object)\v303. \vin an allocator\v421. \vof an array object\v322. \vof a constant\v303. \vof a constant in a static expression\v422. \vof a discriminant of a formal parameter\v602. \vof a discriminant of an object\v327. \vof a limited private type object\v708. \vof an object declared in a package\v701. \vof an out mode formal parameter\v602. \vof a record object\v327. \vINLINE (predefined pragma)\v605. \vcreating recompilation dependence\v1006. \vINOUT_FILE (input-output file_mode enumeration literal)\v1401. \vInput-output\v1400. \vat device level\v1421. \vexceptions\v1419. \vwith a direct access file\v1406. \vwith a sequential file\v1404. \vwith a text file\v1408. \vINTEGER (predefined type)\v314. \vas base type of a loop parameter\v506. \vas default type for the bounds of a discrete range\v322. \vInteger literal\v204. \vas a bound of a discrete range\v905. \vas a universal integer literal\v314. \vin based notation\v206. \vin decimal notation\v205. \uInteger part\n \vas a base of a based literal\v206. \vof a decimal literal\v205. \vInteger predefined type\v314. \uInteger subtype\n \vdue to an integer type definition\v314. \vInteger type\v314. \vas a generic formal type\v1203. \vas a generic parameter\v1209. \voperation\v315. \vresult of a conversion from a numeric type\v419. \vresult of an operation out of range of the type\v411. \vInteger type definition\v314. \vINTEGER_IO (text_io inner generic package)\v1414. \vINTERFACE (predefined pragma)\v1313. \vInterface to other languages\v1313. \vInterrupt\v1305. \vInterrupt entry\v1306. \vIO_EXCEPTIONS (predefined input-output package)\v1419. \vspecification\v1420. IS_OPEN (input-output function) \vin an instance of direct_io\v1403. \vin an instance of sequential_io\v1403. \vin text_io\v1403. \vISO (international organization for standardization)\v201. \vISO seven bit coded character set\v201. \vIteration scheme\v506. \u- L -\n \vLabel\v501. \vdeclaration\v501. \vimplicitly declared\v301. \vlead to by a goto statement\v510. \uLabel bracket\n \vcompound delimiter\v202. \vLabeled statement\v501. \vin a code statement\v1312. \vLARGE (predefined attribute)\v318. \vLAST (predefined attribute)\v1500. \vfor an access value\v332. \vfor an array type\v323. \vfor a scalar type\v310. \vLAST_BIT (predefined attribute)\v1310. \vLater declarative item\v333. \vLAYOUT_ERROR (input-output exception)\v1419. \vLeading zeros in a numeric literal\v205. \vLeft label bracket compound delimiter\v202. \uLeft parenthesis\n \vcharacter\v201. \vdelimiter\v202. \vLegal\v108. \vLENGTH (predefined attribute)\v323. \vfor an access value\v332. \vLength clause\v1302. \vas a representation clause\v1301. \vfor an access type\v421. \vspecifying small of a fixed point type\v1302. \vLength of a string literal\v208. Length of the result \vof an array comparison\v412. \vof an array logical negation\v417. \vof a catenation\v414. \uLess than\n \vcharacter\v201. \vdelimiter\v202. \uLess than or equal\n \vcompound delimiter\v202. \vLetter\v203. \ve or E in a decimal literal\v205. \vin a based literal\v206. \vin an identifier\v203. \vLetter_or_digit\v203. \vLexical element\v200. \vas a point in the program text\v803. \vin a conforming construct\v604. \vtransferred by a text_io procedure\v1408. \vLexicographic order\v413. \uLibrary package\n \vhaving dependent tasks\v904. \uLibrary package body\n \vraising an exception\v1105. \vLibrary unit\v1001. \vcompiled before the corresponding body\v1006. \vfollowed by an inline pragma\v605. \vincluded in the predefined package standard\v806. \vmay not be subject to an address clause\v1305. \vnamed in a use clause\v1008. \vnamed in a with clause\v1002. \vrecompiled\v1006. \vscope\v802. \vsubject to an interface pragma\v1313. \vthat is a package\v701. \vvisibility due to a with clause\v803. \vwhose name is needed in a compilation unit\v1002. \vwith a body stub\v1004. \vLimited private type\v708. \vas a generic actual type\v1208. \vas a generic formal type\v1203. \vLimited type\v708. \vas a full type\v705. \vcomponent of a record\v325. \vgeneric formal object\v1202. \vin an object declaration\v303. \vlimited record type\v329. \voperation\v329. \vparameters for explicitly declared equality operators\v611. \vLine\v1408. \vLINE (text_io function)\v1412. \vraising an exception\v1419. \vLine feed format effector\v201. \vLine length\v1408. \vLine terminator\v1408. \vLINE_LENGTH (text_io function)\v1411. \vraising an exception\v1419. \vLIST (predefined pragma)\v1600. \vLiteral\v406. \vas a basic operation\v308. \vof a derived type\v309. \vof universal_integer type\v314. \vof universal_real type\v314. \vLocal declaration\v801. \vin a generic unit\v1206. \vLogical negation operation\v417. \vLogical operation\v412. \vLogical operator\v411. \vas an operation of boolean type\v315. \vfor an array type\v323. \vin an expression\v410. \voverloaded\v611. \vLogical processor\v900. \vLONG_FLOAT (predefined type)\v317. \vLONG_INTEGER (predefined type)\v314. \vLoop name\v506. \vdeclaration\v501. \vimplicitly declared\v301. \vin an exit statement\v508. \vLoop parameter\v506. \vas an object\v302. \vLoop parameter specification\v506. \vas an overload resolution context\v807. \vis a declaration\v301. \vLoop statement\v506. \vas a compound statement\v501. \vas a declarative region\v801. \ventity denoted by an expanded name\v404. \vincluding an exit statement\v508. \vLOW_LEVEL_IO (predefined input-output package)\v1421. \vLower case letter\v201. \va to f in a based literal\v206. \ve in a decimal literal\v205. \vin an identifier\v203. \u- M -\n \vMachine code insertion\v1312. \vMachine dependent attribute\v1311. \vMACHINE_CODE (predefined package)\v1312. \vMACHINE_EMAX (predefined attribute)\v1311. \vMACHINE_EMIN (predefined attribute)\v1311. \vMACHINE_MANTISSA (predefined attribute)\v1311. \vMACHINE_OVERFLOWS (predefined attribute)\v1311. \vMACHINE_RADIX (predefined attribute)\v1311. \vMACHINE_ROUNDS (predefined attribute)\v1311. \vMain program\v1001. \vexecution requiring elaboration of library units\v1008. \vincluded in the predefined package standard\v806. \vincluding a priority pragma\v911. \vraising an exception\v1105. \vtermination\v904. \vMANTISSA (predefined attribute)\v318. \uMantissa\n \vof a fixed point number\v319. \vof a floating point number\v317. \vMaster (task)\v904. \uMatching components\n \vof arrays\v413. \vof records\v413. \uMatching generic formal\n \vand actual parameters\v1206. \vaccess type\v1211. \varray type\v1210. \vdefault subprogram\v1212. \vobject\v1207. \vprivate type\v1208. \vscalar type\v1209. \vsubprogram\v1212. \vtype\v1208. \vMathematically correct result of a numeric operation\v411. \vMaximum line length\v1408. \vMaximum page length\v1408. \vMembership test\v410. \vcannot be overloaded\v611. \vMembership test operation\v411. \vas a basic operation\v308. \vfor a real type\v418. \vMEMORY_SIZE (predefined pragma)\v1308. \uMinus\n \vcharacter in an exponent of a numeric literal\v205. \vdelimiter\v202. \vunary operation\v415. \uMODE (input-output function)\n \vin an instance of direct_io\v1403. \vin an instance of sequential_io\v1403. \vin text_io\v1403. \vMode (of a file)\v1401. \vof a direct access file\v1402. \vof a sequential access file\v1402. \vof a text_io file\v1409. \vMode (of a parameter)\v602. \vof a formal parameter of a derived subprogram\v309. \vof a formal parameter of a renamed entry or subprogram\v805. \vof a generic form object\v1202. \vMode in out for a formal parameter\v601. \vof a function\v609. \vof an interrupt entry\v1306. \vMode in for a generic formal object\v1202. \vMode in for a formal parameter\v601. \vof a function is not allowed\v609. \vof an interrupt entry is not allowed\v1306. \vMode in out for a generic formal object\v1202. \vMode out for a formal parameter\v601. \vof a function is not allowed\v609. \vof an interrupt entry is not allowed\v1306. \vMODE_ERROR (input-output exception)\v1419. \vModel interval of a subtype\v418. \vModel number (of a real type)\v316. \vaccuracy of a real operation\v418. \vof a fixed point type\v319. \vof a floating point type\v317. \vModulus operation\v416. \vMONTH (predefined function)\v906. \vMultidimensional array\v321. \uMultiple\n \vcomponent definition\v325. \vdeferred constant declaration\v704. \vdiscriminant specification\v326. \vgeneric parameter declaration\v1201. \vnumber declaration\v304. \vobject declaration\v601. \vparameter specification\v601. \vMultiplication operation\v416. \vaccuracy for a real type\v418. \vMultiplying operator\v411. \vin a term\v410. \voverloaded\v611. \vMust (legality requirement)\v108. \vMutually recursive types\v331. \u- N -\n \uNAME (input-output function)\n \vin an instance of direct_io\v1403. \vin an instance of sequential_io\v1403. \vin text_io\v1403. \vName (of an entity)\v401. \vas a prefix\v401. \vas a primary\v410. \vas the argument of a pragma\v210. \vas the expression in a case statement\v505. \vconflicts\v805. \vdeclared by renaming is not allowed as prefix of certain expanded\v404. \vnames\v404. \vdeclared in a generic unit\v1206. \vdenoting an entity\v401. \vdenoting an object designated by an access value\v401. \vstarting with a prefix\v401. \vName string (of a file)\v1401. \vNAME_ERROR (input-output exception)\v1419. \vNamed association\v608. \vNamed number\v302. \vas an entity\v301. \vas a primary\v410. \vin a static expression\v422. \vNATURAL (predefined integer subtype)\v1700. \vNegation operation (numeric)\v415. \uNegative exponent\n \vin a numeric literal\v205. \vto an exponentiation operator\v417. \vNEW_LINE (text_io procedure)\v1412. \vraising an exception\v1419. \vNEW_PAGE (text_io procedure)\v1412. \vraising an exception\v1419. \uNot unary operator\n \vas an operation of an array type\v323. \vas an operation of boolean type\v315. \vin a factor\v410. \vNot yet elaborated\v333. \vNull access value\v330. \vcausing constraint_error\v410. \vnot causing constraint_error\v1109. \vNull array\v322. \vaggregate\v409. \vand relational operation\v413. \vas an operand of a catenation\v414. \vNull component list\v325. \vNull literal\v330. \vas a basic operation\v308. \vas a primary\v410. \vmust not be the argument of a conversion\v419. \vNull range\v310. \vas a choice of a variant part\v328. \vfor a loop parameter\v506. \vNull record\v325. \vand relational operation\v413. \vNull slice\v403. \vNull statement\v501. \vas a simple statement\v501. \vNull string literal\v208. \vNumber declaration\v302. \vas a basic declaration\v301. \vNUMBER_BASE (predefined integer subtype)\v1415. \vNumeric literal\v204. \vand an adjacent separator\v202. \vas a basic operation\v308. \vas a primary\v410. \vas the parameter of value attribute\v315. \vas the result of image attribute\v315. \vassigned\v502. \vcan be written in the basic character set\v212. \vin a conforming construct\v604. \vin a static expression\v422. \vin pragma memory_size\v1308. \vin pragma storage_unit\v1308. \vNumeric operation of a universal type\v423. \vNumeric type\v310. \voperation\v411. \uNumeric type expression\n \vin a length clause\v1302. \vNumeric value of a number declaration\v302. \vNUMERIC_ERROR (predefined exception)\v1101. \vnot raised due to lost overflow conditions\v1315. \vnot raised due to optimization\v1108. \vraised by a numeric operator\v411. \vraised by a predefined integer operation\v314. \vraised by a real result out of range of the safe numbers\v418. \vraised by a universal expression\v423. \vraised by integer division remainder or modulus\v416. \vraised due to a conversion out of range\v314. \u- O -\n \vObject\v302. \vas an actual parameter\v602. \vas a generic formal parameter\v1202. \vcreated by an allocator\v421. \vcreated by elaboration of an object declaration\v303. \vrenamed\v805. \vsubject to an address clause\v1305. \vsubject to a representation clause\v1301. \vsubject to a suppress pragma\v1109. \vObject declaration\v302. \vas a basic declaration\v301. \vas a full declaration\v707. \vimplied by a task declaration\v901. \vin a package specification\v701. \vof an array object\v322. \vof a record object\v327. \vwith a limited type\v708. \vwith a task type\v902. \uObject designated\n \vby an access value\v302. \vby an access value denoted by a name\v401. \vby an access-to-array type\v322. \vby an access-to-record type\v327. \vby a generic formal access type value\v1211. \uObject module\n \vfor a subprogram written in another language\v1313. \vObsolete compilation unit (due to recompilation)\v1006. \vOccur immediately within (a declarative region)\v801. \vOmitted parameter association for a subprogram call\v608. \uOPEN (input-output procedure)\n \vin an instance of direct_io\v1403. \vin an instance of sequential_io\v1403. \vin text_io\v1403. \vraising an exception\v1419. \vOpen alternative\v908. \vaccepting a conditional entry call\v909. \vaccepting a timed entry call\v910. \vOpen file\v1401. \vOperation\v305. \vclassification\v308. \vof an access type\v332. \vof an array type\v323. \vof a discrete type\v315. \vof a fixed point type\v320. \vof a floating point type\v318. \vof a generic actual type\v1203. \vof a generic formal type\v1203. \vof a limited type\v708. \vof a private type\v706. \vof a record type\v329. \vof a subtype\v305. \vof a subtype of a discrete type\v315. \vof a type\v305. \vof a universal type\v423. \vpropagating an exception\v1108. \vsubject to a suppress pragma\v1109. \vOperator\v411. \vas an operation\v308. \vimplicitly declared\v308. \vin an expression\v410. \vin a static expression\v422. \vof a derived type\v309. \vof a generic actual type\v1203. \voverloaded\v611. \vrenamed\v805. \vOperator declaration\v601. \vOperator symbol\v601. \vas a designator\v601. \vas a designator in a function declaration\v411. \vas a name\v401. \vbefore arrow compound delimiter\v803. \vdeclared\v301. \vdeclared in a generic unit\v1206. \vin a renaming declaration\v805. \vin a selector\v404. \vin a static expression\v422. \vnot allowed as the designator of a library unit\v1001. \vof a generic formal function\v1204. \vof homograph declarations\v803. \voverloaded\v611. \vOptimization\v1009. \vand exceptions\v1108. \vOPTIMIZE (predefined pragma)\v1600. \vOrder of application of operators in an expression\v411. \vOrder of compilation (of compilation units)\v1001. \vcreating recompilation dependence\v1006. \vOrder of copying back of out and in out formal parameters\v606. \vOrder of elaboration\v333. \v(of compilation units)\v1008. \vOrder of evaluation\v108. \vand exceptions\v1108. \vof conditions in an if statement\v504. \vof default expressions for components\v303. \vof expressions and the name in an assignment statement\v502. \vof operands in an expression\v411. \vof parameter associations in a subroutine call\v606. \vof the bounds of a range\v310. \vof the conditions in a selective wait\v908. \vOrdering operator\v411. \vOrdering relation\v413. \vfor a real type\v418. \vof an enumeration type preserved by a representation clause\v1303. \vof a scalar type\v310. \vOther special character\v210. \vOthers\v328. \vas a choice in an array aggregate\v409. \vas a choice in a case statement alternative\v505. \vas a choice in a component association\v407. \vas a choice in a record aggregate\v408. \vas a choice in a variant part\v328. \vas an exception choice\v1102. \vOUT_FILE (input-output file_mode enumeration literal)\v1401. \vOverflow of real operations\v418. \vOverlapping slices in array assignment\v503. \vOverlaying of objects or program units\v1305. \vOverloading\v803. \vand visibility\v803. \vin an assignment statement\v502. \vin an expression\v410. \vresolution\v610. \vresolution context\v807. \vresolved by explicit qualification\v420. \uOverloading of\n \van aggregate\v309. \van allocator\v421. \va declaration\v803. \va designator\v610. \van entry\v905. \van enumeration literal\v311. \va generic formal subprogram\v1206. \va generic unit\v1201. \van identifier\v610. \va library unit by a locally declared subprogram\v1001. \va library unit by means of renaming\v1001. \va literal\v406. \va membership test\v413. \van operator\v411. \van operator symbol\v610. \va subprogram\v610. \va subprogram subject to an interface pragma\v1313. \vthe expression in a case statement\v505. \u- P -\n \vPACK (predefined pragma)\v1301. \vPackage\v700. \vas a generic instance\v1206. \vincluding a raise statement\v1103. \vnamed in a use clause\v804. \vrenamed\v805. \vsubject to an address clause\v1305. \vsubject to representation clause\v1301. \vwith a separately compiled body\v1004. \vPackage body\v701. \vas a generic body\v1205. \vas a proper body\v333. \vas a secondary unit\v1001. \vas a secondary unit compiled after the corresponding library unit\v1006. \vin another package body\v701. \vincluding an exception handler\v1102. \vincluding an exit statement\v508. \vincluding a goto statement\v510. \vincluding an implicit declaration\v501. \vmust be in the same declarative part as the declaration\v333. \vraising an exception\v1105. \vrecompiled\v1006. \vsubject to a suppress pragma\v1109. \vPackage declaration\v701. \vand body as a declarative region\v801. \vas a basic declaration\v301. \vas a later declarative item\v333. \vas a library unit\v1001. \vdetermining the visibility of another declaration\v803. \velaboration raising an exception\v1106. \vin a package specification\v701. \vrecompiled\v1006. \vPackage identifier\v701. \vPackage specification\v701. \vin a generic declaration\v1201. \vincluding an inline pragma\v605. \vincluding an interface pragma\v1313. \vincluding a representation clause\v1301. \vincluding a suppress pragma\v1109. \vPage\v1412. \vPAGE (predefined pragma)\v1600. \vPAGE (text_io function)\v1411. \vraising an exception\v1419. \vPage length\v1408. \vPage terminator\v1408. \vPAGE_LENGTH (text_io function)\v1411. \vraising an exception\v1419. \vParagraphing recommended for the layout of programs\v107. \vParameter\v1800. \vof a main program\v1001. \vParameter and result type profile\v610. \vParameter association\v606. \vfor a derived subprogram\v309. \vnamed parameter association\v606. \vnamed parameter association for selective visibility\v803. \vomitted for a subprogram call\v608. \vpositional parameter association\v606. \vParameter specification\v601. \vas part of a basic declaration\v301. \vhaving an extended scope\v802. \vin a formal part\v601. \vvisibility\v803. \vParameter type profile\v610. \vParent subprogram (of a derived subprogram)\v309. \vParent subtype (of a derived subtype)\v309. \vParent type (of a derived type)\v309. \vdeclared in a visible part\v309. \vof a generic actual type\v1203. \vof a numeric type is predefined and anonymous\v314. \vParent unit (of a body stub)\v1004. \vcompiled before its subunits\v1006. \uParenthesis\n \vcharacter\v201. \vdelimiter\v202. \uParenthesized expression\n \vas a primary\v410. \vin a static expression\v422. \vPartial ordering of compilation\v1006. \vPercent character\v201. \vreplacing quotation character\v212. \vPeriod character\v201. \vPhysical processor\v900. \uPlus\n \vcharacter\v201. \vdelimiter\v202. \vunary operation\v415. \vPoint character\v201. \vin a based literal\v206. \vin a decimal literal\v205. \vin a numeric literal\v204. \vPoint delimiter\v202. \vPortability\v101. \vof programs using real types\v1311. \vPOS (predefined attribute)\v315. \vPOSITION (predefined attribute)\v1310. Position number \vas parameter to val attribute\v315. \vof an enumeration literal\v311. \vof an integer value\v314. \vof a value of a discrete type\v310. \vreturned by pos attribute\v315. \vPosition of an element in a direct access file\v1402. \vPositional association\v606. \vPOSITIVE (predefined integer subtype)\v324. \vas the index type of the string type\v324. \vPOSITIVE_COUNT (predefined integer subtype)\v1407. \vPotentially visible declaration\v804. \vPound sterling character\v201. \vPragma\v210. \vapplicable to the whole of a compilation\v1001. \vargument that is an overloaded subprogram name\v323. \vfor the specification of a subprogram body in another language\v1313. \vfor the specification of program overlays\v1305. \vin a code procedure body\v1312. \vrecommending the representation of an entity\v1301. \vspecifying implementation conventions for code statements\v1312. \uPragma (predefined)\n \vCONTROLLED\v421. \vELABORATE\v1008. \vINLINE\v605. \vINTERFACE\v1313. \vLIST\v1600. \vMEMORY_SIZE\v1308. \vOPTIMIZE\v1600. \vPACK\v1301. \vPAGE\v1600. \vPRIORITY\v911. \vSHARED\v914. \vSTORAGE_UNIT\v1308. \vSUPPRESS\v1109. \vSYSTEM_NAME\v1308. \vPrecedence\v411. \vPRED (predefined attribute)\v315. \vPredefined constant\v806. \vPredefined exception\v806. \vPredefined function\v806. \vPredefined generic library function\v806. \vPredefined generic library package\v806. \vPredefined generic library procedure\v806. \vPredefined generic library subprogram\v806. \vPredefined identifier\v806. \vPredefined library package\v806. \vPredefined operation\v305. \vaccuracy for a real type\v418. \vof a discrete type\v315. \vof a fixed point type\v320. \vof a universal type\v423. \vpropagating an exception\v1108. \vPredefined operator\v411. \vapplied to an undefined value\v303. \vas an operation\v308. \vfor an access type\v332. \vfor an array type\v323. \vfor a record type\v329. \vimplicitly declared\v308. \vin a static expression\v422. \vof a derived type\v309. \vof a fixed point type\v319. \vof a floating point type\v317. \vof an integer type\v314. \vraising an exception\v1105. \vPredefined package\v806. \vfor input-output\v1400. \vPredefined subprogram\v806. \vPredefined subtype\v806. \vPredefined type\v806. \vPrefix\v401. \vin an attribute\v405. \vin an indexed component\v402. \vin a selected component\v404. \vin a slice\v403. \vthat is a function call\v401. \vthat is a name\v401. \vPrimary\v410. \vin a factor\v410. \vin a static expression\v422. \vPRIORITY (predefined integer subtype)\v911. \vPRIORITY (predefined pragma)\v911. \vPrivate part (of a package)\v702. \vPrivate type\v305. \vas a generic actual type\v1208. \vas a generic formal type\v1203. \vas a parent type\v309. \vcorresponding full type declaration\v306. \vformal parameter\v602. \vof a deferred constant\v704. \voperation\v706. \vPrivate type declaration\v704. \vas a generic type declaration\v1201. \vas a portion of a declarative region\v801. \vincluding the word 'limited'\v708. \vProcedure\v601. \vas a main program\v1001. \vas a renaming of an entry\v905. \vrenamed\v805. \uProcedure body\n \vincluding code statements\v1312. \vProcedure call\v606. \vProcedure call statement\v606. \vas a simple statement\v501. \vwith a parameter of a derived type\v309. \vProcessor\v900. \vProgram\v1000. \vProgram legality\v108. \vProgram library\v1001. \vcreation\v1007. \vmanipulation and status\v1007. \vProgram optimization\v1008. \vProgram text\v202. \vProgram unit\v600. \ventity denoted by an expanded name\v404. \vincluding a suppress pragma\v1109. \vsubject to an address clause\v1305. \vwith a separately compiled body\v1004. \vPROGRAM_ERROR (predefined exception)\v1101. \vraised by an erroneous program or incorrect order dependence\v108. \vraised by a generic instantiation before elaboration of the body\v333. \vraised by a subprogram call before elaboration of the body\v333. \vraised by a task activation before elaboration of the body\v333. \vraised by reaching the end of a function body\v609. \vProper body\v333. \vas a body\v333. \vin a subunit\v1004. \vof a library unit separately compiled\v1001. \vPUT (text_io procedure)\v1408. \vfor character and string types\v1414. \vfor enumeration types\v1417. \vfor integer types\v1415. \vfor real types\v1416. \vraising an exception\v1419. \u- Q -\n \vQualification\v420. \vas a basic operation\v308. \vusing a name of an enumeration type as qualifier\v311. \vQualified expression\v420. \vas a primary\v410. \vin an allocator\v421. \vin a case statement\v505. \vin a static expression\v422. \vqualification of an array aggregate\v409. \vto resolve an overloading ambiguity\v610. \vQuotation character\v201. \vin a string literal\v208. \vreplacement by percent character\v212. \u- R -\n \vRadix of a floating point type\v317. \vRaise statement\v1103. \vas a simple statement\v501. \vincluding the name of an exception\v1101. \vRaising of an exception\v1100. \vcausing a transfer of control\v501. \vRange\v310. \vas a discrete range\v321. \vin a record representation clause\v1304. \vin a relation\v410. \vof an index subtype\v321. \vof an integer type containing the result of an operation\v411. \vof a predefined integer type\v314. \vof a real type containing the result of an operation\v418. \vyielded by an attribute\v405. \vRANGE (predefined attribute)\v323. \vfor an access value\v332. \vfor an array type\v323. \vRange constraint\v310. \vignored due to range_check suppression\v1109. \vin a fixed point constraint\v319. \vin a floating point constraint\v317. \vin an integer type definition\v314. \vin a subtype indication\v310. \von a derived subtype\v309. \vviolated\v1101. \uREAD (input-output procedure)\n \vin an instance of direct_io\v1406. \vin an instance of sequential_io\v1404. \vReading the value of an object\v602. \vReal literal\v204. \vin based notation\v206. \vin decimal notation\v205. \vis of universal_real type\v316. \vReal type\v316. \vaccuracy of an operation\v418. \vrepresentation attribute\v1311. \vresult of a conversion from a numeric type\v418. \vresult of an operation out of range of the type\v411. \vReal type definition\v316. \vRECEIVE_CONTROL (low_level_io procedure)\v1421. \vReciprocal operation in exponentiation by a negative integer\v417. \vRecompilation\v1006. \vRecord aggregate\v408. \vas a basic operation\v308. \vin a code statement\v1312. \vRecord representation clause\v1304. \vas a representation clause\v1301. \vRecord type\v325. \vformal parameter\v602. \vincluding a limited subcomponent\v708. \voperation\v329. \uRecord type declaration\n \vas a declarative region\v801. \vdetermining the visibility of another declaration\v803. \vRecord type definition\v307. \uRecursive\n \vcall of a subprogram\v601. \vgeneric instantiation\v1201. \vtypes\v331. \vReentrant subprogram\v601. \vReference (parameter passing)\v602. \vRelation (in an expression)\v410. \vRelational operation\v413. \vof a boolean type\v313. \vof a discrete type\v315. \vof a fixed point type\v320. \vof a real type\v418. \vof a scalar type\v310. \vresult for real operands\v418. \vRelational operator\v411. \vfor an access type\v332. \vfor an array type\v323. \vfor a private type\v706. \vfor a record type\v329. \vfor time predefined type\v906. \vin a relation\v410. \voverloaded\v611. \vRem operator\v416. \vRemainder operation\v416. \vRenaming declaration\v805. \vas a basic declaration\v301. \vas a declarative region\v801. \vcannot rename a universal_fixed operation\v416. \vfor an array object\v322. \vfor an entry\v905. \vfor a record object\v327. \vname declared is not allowed as a prefix of certain expanded names\v404. \vto overload a library unit\v1001. \vto overload a subunit\v1002. \vto resolve an overloading ambiguity\v610. \vRendezvous (of tasks)\v905. \vduring which an exception is raised\v1107. \vpriority\v911. \vprohibited for an abnormal task\v913. \vReplacement of characters in program text\v212. \vRepresentation (of a type and its objects)\v1301. \vrecommendation by a pragma\v1301. \vRepresentation attribute\v1310. \vas a forcing occurrence\v1301. \vprefix which has a null value\v401. \vRepresentation clause\v1301. \van an overload resolution context\v807. \vas a basic declarative item\v333. \vas a portion of a declarative region\v801. \vcannot include a forcing occurrence\v1301. \vfor a derived type\v309. \vfor a private type\v705. \vimplied for a derived type\v309. \vin an overload resolution context\v807. \vin a task specification\v901. \vReserved word\v211. \uRESET (input-output procedure)\n \vin an instance of direct_io\v1403. \vin an instance of sequential_io\v1403. \vin text_io\v1403. \vResult subtype (of a function)\v601. \vof a return expression\v509. \vResult type and overload resolution\v610. \vReturn statement\v509. \vas a simple statement\v501. \vcausing a loop to be exited\v506. \vcausing a transfer of control\v501. \vcompleting block statement execution\v904. \vcompleting subprogram execution\v904. \vexpression which is an array aggregate\v409. \vin a function body\v609. \uReturned value\n \vof a function call\v509. \vof an instance of a generic formal function\v1204. \vof a main program\v1001. \vof an operation\v308. \vof a predefined operator of an integer type\v314. \vof a predefined operator of a real type\v316. \vRight label bracket compound delimiter\v202. \uRight parenthesis\n \vcharacter\v201. \vdelimiter\v202. \uRounding\n \vin a real-to-integer conversion\v419. \vof results of real operations\v418. \vRun time check\v1109. \u- S -\n \vSafe interval\v418. \vSafe number (of a real type)\v316. \vlimit to the result of a real operation\v418. \vof a fixed point type\v319. \vof a floating point type\v317. \vresult of universal expression too large\v423. \vSAFE_EMAX (predefined attribute)\v318. \vSAFE_LARGE (predefined attribute)\v318. \vSAFE_SMALL (predefined attribute)\v318. \vSatisfy (a constraint)\v305. \va discriminant constraint\v327. \van index constraint\v322. \va range constraint\v310. \vScalar type\v305. \vas a generic parameter\v1203. \vformal parameter\v602. \vof a range in a membership test\v413. \voperation\v315. \vScheduling\v911. \vScope\v802. \vof a use clause\v804. \vSecondary unit\v1001. \vcompiled after the corresponding library unit or parent unit\v1006. \vsubject to pragma elaborate\v1008. \vSECONDS (predefined function)\v906. \vSelect alternative (of a selective wait)\v908. \vSelect statement\v907. \vas a compound statement\v501. \vin an abnormal task\v913. \vSelected component\v404. \vas a basic operation\v308. \vas a name\v401. \vas the name of an entry or entry family\v905. \vfor selective visibility\v803. \vin a conforming construct\v604. \vstarting with standard\v806. \vusing a block name\v507. \vusing a loop name\v506. \vwhose prefix denotes a package\v803. \vwhose prefix denotes a record object\v803. \vwhose prefix denotes a task object\v803. \vSelection of an exception handler\v1104. \vSelective wait\v908. \vaccepting a conditional entry call\v909. \vaccepting a timed entry call\v910. \vraising program_error\v1101. \vSelector\v404. \vSemicolon character\v201. \vSemicolon delimiter\v202. \vfollowed by a pragma\v210. \vSEND_CONTROL (low_level_io procedure)\v1421. \vSeparate compilation\v1000. \vof a proper body\v333. \vof a proper body declared in another compilation unit\v1004. \vSeparator\v202. \vSequence of statements\v501. \vin an accept statement\v905. \vin a basic loop\v506. \vin a block statement\v507. \vin a case statement alternative\v505. \vin a conditional entry call\v909. \vin an exception handler\v1102. \vin an if statement\v504. \vin a package body\v701. \vin a selective wait statement\v908. \vin a subprogram body\v603. \vin a task body\v901. \vin a timed entry call\v910. \vincluding a raise statement\v1103. \vof code statements\v1312. \vraising an exception\v1105. \vSequential access file\v1402. \vSequential input-output\v1404. \vSEQUENTIAL_IO (predefined input-output generic package)\v1402. \vexceptions\v1419. \vspecification\v1405. \vSET_COL (text_io procedure)\v1412. \vSET_INDEX (input-output procedure) in an instance of direct_io\v1406. \vSET_INPUT (text_io procedure)\v1410. \vraising an exception\v1419. \vSET_LINE (text_io procedure)\v1412. \vSET_LINE_LENGTH (text_io procedure)\v1411. \vraising an exception\v1419. \vSET_OUTPUT (text_io procedure)\v1410. \vraising an exception\v1419. \vSET_PAGE_LENGTH (text_io procedure)\v1411. \vraising an exception\v1419. \vSHARED (predefined pragma)\v914. \vShared variable (of two tasks)\v914. \vSharp character\v201. \vreplacement by colon character\v212. \vShort circuit control form\v411. \vas a basic operation\v308. \vin an expression\v410. \vSHORT_FLOAT (predefined type)\v317. \vSHORT_INTEGER (predefined type)\v314. \vSign of a fixed point number\v319. \vSign of a floating point number\v317. \vSignificant decimal digits\v317. \vSimple expression\v410. \vas a choice\v328. \vas a choice in an aggregate\v407. \vas a range bound\v310. \vfor an entry index in an accept statement\v905. \vin an address clause\v1305. \vin a delay statement\v906. \vin a fixed accuracy definition\v319. \vin a floating accuracy definition\v317. \vin a record representation clause\v1304. \vin a relation\v410. \vSimple name\v401. \vas a choice\v328. \vas a formal parameter\v606. \vas a label\v501. \vas a name\v401. \vbefore arrow compound delimiter\v803. \vin an accept statement\v905. \vin an address clause\v1305. \vin an attribute designator\v405. \vin a conforming construct\v604. \vin a discriminant association\v327. \vin an enumeration representation clause\v1303. \vin a package body\v701. \vin a selector\v404. \vin a suppress pragma\v1109. \vin a task body\v901. \vin a variant part\v328. \vin a with clause\v1002. \vversus identifier\v301. \vSimple statement\v501. \uSIZE (input-output function)\n \vin an instance of direct_io\v1406. \vSIZE (predefined attribute)\v1310. \vspecified by a length clause\v1302. \vSKIP_LINE (text_io procedure)\v1412. \vraising an exception\v1419. \vSKIP_PAGE (text_io procedure)\v1412. \vraising an exception\v1419. \vSlice\v403. \vas a basic operation\v308. \vas a name\v401. \vas destination of an assignment\v503. \vof a constant\v303. \vof a derived type\v309. \vof an object as an object\v302. \vof a value of a generic formal array type\v1203. \vof a variable\v303. \vstarting with a prefix\v401. \vSMALL (predefined attribute)\v318. \vspecified by a length clause\v1302. \vSmall of a fixed point number\v319. \vSpace character\v201. \vas a separator\v202. \vin a comment\v209. \vnot allowed in an identifier\v203. \vnot allowed in a numeric literal\v205. \vSpace character literal\v207. \vSpecial character\v201. \vin a delimiter\v202. \vSTANDARD (predefined package)\v806. \vas a declarative region\v801. \venclosing the library units of a program\v1002. \vincluding implicit declarations of fixed point\v416. \vcross-multiplication and cross-division\v416. \vSTANDARD_INPUT (text_io function)\v1410. \vSTANDARD_OUTPUT (text_io function)\v1410. \uStar\n \vcharacter\v201. \vdelimiter\v202. \vStatement\v501. \vallowed in an exception handler\v1102. \vas an overload resolution context\v807. \voptimized\v1009. \vraising an exception\v1105. \vthat cannot be reached\v1009. \vStatic constraint\v422. \von a subcomponent subject to a component clause\v1304. \von a type\v314. \vStatic discrete range\v422. \vas a choice of an aggregate\v409. \vas a choice of a case statement\v505. \vas a choice of a variant part\v328. \vStatic expression\v422. \vas a bound in an integer type definition\v314. \vas a choice in a case statement\v505. \vas a choice of a variant part\v328. \vfor a choice in a record aggregate\v409. \vfor a discriminant in a record aggregate\v408. \vin an attribute designator\v405. \vin an enumeration representation clause\v1303. \vin a fixed accuracy definition\v319. \vin a floating accuracy definition\v317. \vin a generic unit\v1201. \vin a length clause\v1302. \vin a number declaration\v302. \vin a record representation clause\v1304. \vin priority pragma\v911. \vwhose type is a universal type\v423. \vStatic others choice\v409. \vStatic subtype\v422. \vof a discriminant\v328. \vof the expression in a case statement\v505. \vSTATUS_ERROR (input-output exception)\v1419. \vStorage address of a component\v1304. \uStorage bits\n \vallocated to an object or type\v1302. \vof a record component relative to a storage unit\v1304. \vsize of a storage unit\v1308. \vStorage reclamation\v421. \vStorage representation of a record\v1304. \vStorage unit\v1308. \voffset to the start of a record component\v1304. \vsize of a storage unit in bits\v1308. \uStorage units allocated\n \vto a collection\v1302. \vto a task activation\v1302. \vSTORAGE_ERROR (predefined exception)\v1101. \vraised by an allocator exceeding the allocated storage\v421. \vraised by an elaboration of a declarative item\v1101. \vraised by a task activation exceeding the allocated storage\v1101. \vraised by the execution of a subprogram call\v1101. \vSTORAGE_SIZE (predefined attribute)\v1310. \vfor an access type\v332. \vfor a task object or task type\v912. \vspecified by a length clause\v1302. \vSTORAGE_UNIT (predefined pragma)\v1308. \vSTRING (predefined type)\v324. \vas the parameter of value attribute\v315. \vas the result of image attribute\v315. \vString bracket\v208. \vString literal\v208. \vas a basic operation\v308. \vas an operator symbol\v601. \vas a primary\v410. \vmay not be the argument of a conversion\v419. \vreplaced by a catenation of basic characters\v212. \vSubaggregate\v409. \vSubcomponent\v305. \vdepending on a discriminant\v326. \vof a component for which a component clause is given\v1304. \vrenamed\v805. \vthat is a task object\v902. \vwhose type is a limited type\v708. \vwhose type is a private type\v705. \vSubprogram\v600. \vas a generic instance\v1206. \vas a main program\v1001. \vas an operation\v308. \vincluding a raise statement\v1103. \vof a derived type\v309. \voverloaded\v610. \vrenamed\v805. \vsubject to an address clause\v1305. \vsubject to an inline pragma\v605. \vsubject to an interface pragma\v1313. \vsubject to a representation clause\v1301. \vsubject to a suppress pragma\v1109. \vwith a separately compiled body\v1002. \vSubprogram body\v603. \vas a generic body\v1205. \vas a library unit\v1001. \vas a proper body\v333. \vas a secondary unit\v1001. \vas a secondary unit compiled after the corresponding library unit\v1006. \vhaving dependent tasks\v904. \vin a package body\v701. \vincluding an exception handler\v1102. \vincluding an exit statement\v508. \vincluding a goto statement\v510. \vincluding an implicit declaration\v501. \vincluding a return statement\v508. \vincluding code statements must be a procedure body\v1312. \vinlined in place of each call\v605. \vmust be in the same declarative part as the declaration\v333. \vnot allowed for a subprogram subject to an interface pragma\v1313. \vnot yet elaborated at a call\v333. \vraising an exception\v1105. \vrecompiled\v1006. \vSubprogram call\v606. \vbefore elaboration of the body\v333. \vstatement replaced by an inlining of the body\v605. \vstatement with a default actual parameter\v608. \vto a derived subprogram\v309. \vto a generic instance\v1200. \vSubprogram declaration\v601. \vand body as a declarative region\v801. \vas a basic declaration\v301. \vas a later declarative item\v333. \vas a library unit\v1001. \vas an overloaded declaration\v803. \vimplied by the body\v603. \vin a package specification\v701. \vmade directly visible by a use clause\v804. \vof an operator\v611. \vrecompiled\v1006. \vSubprogram specification\v601. \vand forcing occurrence\v1301. \vconforming to another\v604. \vfor a function\v609. \vin a body stub\v1004. \vin a generic declaration\v1201. \vin a renaming declaration\v805. \vin a subprogram body\v603. \vincluding the name of a private type\v705. \vof a derived subprogram\v309. \vSubtraction operation\v414. \vfor a real type\v418. \vSubtype\v305. \vdeclared by a numeric type declaration\v314. \vin a membership test\v413. \vnot considered in overload resolution\v807. \vof an access type\v330. \vof an actual parameter\v607. \vof a component of an array\v321. \vof a component of a record\v325. \vof a constant in a static expression\v422. \vof a discriminant of a generic formal type\v1208. \vof a formal parameter\v607. \vof a formal parameter or result of a renamed subprogram or entry\v805. \vof a generic formal type\v1203. \vof an index of a generic formal array type\v1210. \vof a private type\v704. \vof a real type\v317. \vof a scalar type\v310. \vof a task type\v902. \vof a variable\v502. \vsubject to a representation clause\v1301. \vSubtype conversion\v419. \vin an array assignment\v503. \vto a real type\v418. \vSubtype declaration\v307. \vand forcing occurrences\v1301. \vas a basic declaration\v301. \vincluding the name of a private type\v705. \vSubtype indication\v307. \vas a component subtype indication\v325. \vas a discrete range\v321. \vfor a subtype of a generic formal type\v1203. \vin an access type definition\v330. \vin an allocator\v421. \vin an array type definition\v321. \vin a component declaration\v325. \vin a constrained array definition\v321. \vin a derived type definition\v309. \vin a generic formal part\v1201. \vin an object declaration\v302. \vin an unconstrained array definition\v321. \vincluding a fixed point constraint\v319. \vincluding a floating point constraint\v317. \vwith a range constraint\v310. \vSubunit\v1004. \vas a compilation unit\v1007. \vas a library unit\v1007. \vas a secondary unit\v1001. \vcompiled after the corresponding parent unit\v1006. \vnot allowed for a subprogram subject to an interface pragma\v1313. \vof a compilation unit subject to a context clause\v1002. \vraising an exception\v1105. \vrecompiled (does not affect other compilation units)\v1006. \vSUCC (predefined attribute)\v315. \vSUPPRESS (predefined pragma)\v1109. \vSyntactic category\v107. \vSyntax notation\v107. \vSyntax rule\v107. \vSYSTEM (predefined library package)\v1308. \vSystem dependent\v2000. \vattribute\v1304. \vconstant\v1308. \vnamed number\v1308. \vrecord component\v1304. \vtype\v1308. \vSYSTEM.ADDRESS (predefined type)\v1308. \vSYSTEM.FINE_DELTA (predefined named number)\v1309. \vSYSTEM.MAX_DIGITS (predefined named number)\v1309. \vlimit on the significant digits of a floating point type\v317. \vSYSTEM.MAX_INT (predefined named number)\v1309. \vexceeded by the value of a universal expression\v423. \vSYSTEM.MAX_MANTISSA (predefined named number)\v1309. \vSYSTEM.MEMORY_SIZE (predefined named number)\v1308. \vSYSTEM.MIN_INT (predefined named number)\v1309. \vgreater than the value of a universal expression\v423. \vSYSTEM.NAME (predefined type)\v1308. \vSYSTEM.STORAGE_UNIT (predefined named number)\v1308. \vSYSTEM.SYSTEM_NAME (predefined constant)\v1308. \vSYSTEM.TICK (predefined named number)\v1309. \vSYSTEM_NAME (predefined pragma)\v1308. \u- T -\n \uTabulation\n \vhorizontal\v201. \vvertical\v201. \vTarget statement (of a goto statement)\v510. \vTarget type of a conversion\v419. \vTask\v900. \vcalling the main program\v1001. \vraising an exception\v1107. \vscheduling\v911. \vsuspension awaiting a rendezvous\v905. \vsuspension by a selective wait\v908. \vsuspension of an abnormal task\v913. \vTask activation\v903. \vbefore elaboration of the body\v333. \vcausing synchronization\v913. \vnot started for an abnormal task\v913. \vof a task with no task body\v1101. \vTask body\v901. \vas a proper body\v333. \vin a package body\v701. \vincluding an exception handler\v1102. \vincluding an exit statement\v508. \vincluding a goto statement\v510. \vincluding an implicit declaration\v501. \vmust be in the same declarative part as the declaration\v333. \vnot yet elaborated at an activation\v333. \vraising an exception\v1105. \vspecifying the execution of a task\v902. \vTask declaration\v901. \vand body as a declarative region\v801. \vas a basic declaration\v301. \vas a later declarative item\v333. \velaboration raising an exception\v1106. \vin a package specification\v701. \uTask designated\n \vby a formal parameter\v602. \vby a value of a task type\v901. \vTask execution\v903. \vTask object\v902. \vdesignated by an access value\v902. \vdetermining task dependence\v904. \vrenamed\v805. \vTask priority\v911. \vof a task with an interrupt entry\v1306. \vTask specification\v901. \vincluding an entry declaration\v905. \vincluding a priority pragma\v911. \vincluding a representation clause\v1301. \vTask synchronization\v905. \vTask type\v901. \vcompleting an incomplete type definition\v331. \vformal parameter\v602. \vobject initialization\v303. \vvalue designating a task object\v303. \vTask unit\v901. \vdeclaration determining the visibility of another declaration\v803. \vincluding a raise statement\v1103. \vsubject to an address clause\v1305. \vsubject to a representation clause\v1301. \vsubject to a suppress pragma\v1109. \vwith a separately compiled body\v1004. \vTASKING_ERROR (predefined exception)\v1101. \vraised by an entry call to an abnormal task\v913. \vraised by an entry call to a completed task\v905. \vraised by an exception in the task body\v1106. \vraised by failure of an activation\v903. \vTerm\v410. \vin a simple expression\v410. \vTerminate alternative (of a selective wait)\v908. \vcausing a transfer of control\v501. \vin a select statement causing a loop to be exited\v506. \vselection\v904. \vselection in the presence of an accept alternative for\v1306. \van interrupt entry\v1306. \vTERMINATED (predefined attribute) for a task object\v912. \vTerminated task\v904. \vnot becoming abnormal\v913. \vobject designated by an access value\v421. \vtermination of a task during its activation\v903. \vText input-output\v1408. \vText of a program\v202. \vTEXT_IO (predefined input-output package)\v1408. \vexceptions\v1419. \vspecification\v1418. \vTIME (predefined type)\v906. \vTIME_OF (predefined function)\v906. \vTimed entry call\v910. \vand renamed entries\v805. \vsubject to an address clause\v1306. \vTRUE boolean enumeration literal\v313. \vType\v305. \vname\v306. \vof an actual parameter\v607. \vof an aggregate\v408. \vof an array component of a generic formal array type\v1210. \vof an array index of a generic formal array type\v1210. \vof a case statement expression\v505. \vof a condition\v504. \vof a declared object\v302. \vof a discriminant of a generic formal private type\v1208. \vof an expression\v410. \vof a file\v1401. \vof a formal parameter of a generic formal subprogram\v1204. \vof a generic actual object\v1207. \vof a generic formal object\v1202. \vof an index\v402. \vof a loop parameter\v506. \vof a named number\v302. \vof an object designated by a generic formal access types\v1211. \vof a primary in an expression\v410. \vof a shared variable\v914. \vof a slice\v403. \vof a task object\v902. \vof a universal expression\v423. \vof a value\v305. \vof discriminants of a generic formal object and the matching\v1208. \vactual object\v1208. \vof the literal null\v406. \vof the result of a generic formal function\v1204. \vrenamed\v805. \vsubject to a representation clause\v1301. \vsubject to a suppress pragma\v1109. \vyielded by an attribute\v405. \vType conversion\v419. \vas an actual parameter\v606. \vas a primary\v410. \vin a static expression\v422. \vto a real type\v418. \vType declaration\v306. \vas a basic declaration\v301. \vas a full declaration\v705. \vimplicitly declaring operations\v308. \vin a package specification\v701. \vincluding the name of a private type\v705. \vof a fixed point type\v319. \vof a floating point type\v317. \vof an integer type\v314. \vof a subtype\v1301. \vType definition\v306. \vType mark (denoting a type or subtype)\v307. \vas a generic actual parameter\v1206. \vin an allocator\v421. \vin a code statement\v1312. \vin a conversion\v419. \vin a deferred constant declaration\v704. \vin a discriminant specification\v326. \vin a generic formal part\v1201. \vin a generic parameter declaration\v1207. \vin an index subtype definition\v321. \vin a parameter specification\v601. \vin a qualified expression\v420. \vin a relation\v410. \vin a renaming declaration\v805. \vin a subprogram specification\v601. \vof a formal parameter of a generic formal subprogram\v1204. \vof a generic formal array type\v1203. \vof a static scalar subtype\v422. \vof the result of a generic formal function\v1204. \vType with discriminants\v305. \vas an actual to a formal private type\v1208. \vas the component type of an array that is the operand\v419. \vof a conversion\v419. \u- U -\n \vUnary adding operator\v410. \vas an operation of a discrete type\v315. \vin a simple expression\v410. \voverloaded\v611. \vUnary operator\v411. \vas an operation of a fixed point type\v311. \vUNCHECKED_CONVERSION (predefined generic library function)\v1316. \vUNCHECKED_DEALLOCATION (predefined generic library procedure)\v1315. \vUnconstrained array definition\v321. \vUnconstrained array type\v321. \vas an actual to a formal private type\v1208. \vformal parameter\v602. \vsubject to a length clause\v1302. \vUnconstrained subtype\v305. \vindication in a generic unit\v1208. \vUnconstrained type\v305. \vformal parameter\v602. \vwith discriminants\v607. \vUnconstrained variable\v305. \uUndefined value\n \vof a scalar parameter\v602. \vof a scalar variable\v303. \vUnderline character\v201. \vin a based literal\v206. \vin a decimal literal\v205. \vin an identifier\v203. \vUnhandled exception\v1105. \vUniversal expression\v423. \vassigned\v502. \vin an attribute designator\v405. \vof a real type implicitly converted\v418. \vthat is static\v423. \vUniversal type\v423. \vof a named number\v304. \vUNIVERSAL_FIXED (predefined type)\v319. \vresult of fixed point multiplying operators\v416. \vUNIVERSAL_INTEGER (predefined type)\v314. \vargument to a conversion\v308. \vattribute\v315. \vbounds of a discrete range\v322. \vbounds of a loop parameter\v506. \vcodes representing enumeration type values\v1303. \vconverted to an integer type\v315. \vof integer literals\v204. \vresult of an operation\v423. \vUNIVERSAL_REAL (predefined type)\v316. \vargument to a conversion\v308. \vattribute\v1309. \vconverted to a fixed point type\v320. \vconverted to a floating point type\v318. \vof real literals\v204. \vresult of an operation\v423. \vUpdating the value of an object\v602. \vUpper case letter\v201. \vA to F in a based literal\v206. \vE in a decimal literal\v205. \vin an identifier\v203. \vUse clause (to achieve direct visibility)\v804. \vas a basic declarative item\v333. \vas a later declarative item\v333. \vin a code procedure body\v1312. \vin a context clause of a compilation unit\v1002. \vin a context clause of a subunit\v1004. \vinserted by the environment\v1007. \vUSE_ERROR (input-output exception)\v1419. \u- V -\n \vVAL (predefined attribute)\v315. \uValue\n \vin a constant\v303. \vin a task object\v902. \vin a variable\v303. \vof an array type\v321. \vof a based literal\v206. \vof a boolean type\v313. \vof a character literal\v207. \vof a character type\v312. \vof a decimal literal\v205. \vof a fixed point type\v319. \vof a floating point type\v317. \vof a record type\v325. \vof a record type with discriminants\v326. \vof a string literal\v208. \vof a string type\v324. \vVALUE (predefined attribute)\v315. \vVariable\v303. \vas an actual parameter\v602. \vdeclared in a package body\v703. \vformal parameter\v602. \vin an assignment statement\v502. \vof an array type as destination of an assignment\v503. \vof a private type\v705. \vrenamed\v805. \vthat is a slice\v403. \vVariable declaration\v303. \vVariant\v328. \vin a variant part\v328. \vVariant part\v328. \vin a component list\v325. \vin a record aggregate\v408. \vVertical bar character\v201. \vreplacement by exclamation character\v212. \vVertical bar delimiter\v202. \vVertical tabulation format effector\v201. \vVisibility\v803. \vand renaming\v805. \vdetermining multiple meanings of an identifier\v804. \vdetermining order of compilation\v1006. \vdue to a use clause\v804. \vof a basic operation\v803. \vof a character literal\v803. \vof a default for a generic formal subprogram\v1212. \vof a generic formal parameter\v1206. \vof a library unit due to a with clause\v806. \vof a name of an exception\v1102. \vof an operation declared in a package\v706. \vof an operator symbol\v803. \vof a renaming declaration\v805. \vof a subprogram declared in a package\v603. \vof declarations in a package body\v703. \vof declarations in a package specification\v702. \vof declarations in the package system\v1308. \vwithin a subunit\v1004. \vVisibility by selection\v803. \vVisible part (of a package)\v702. \vexpanded name denoting a declaration in a visible part\v802. \vuse clause naming the package\v804. \vvisibility of a declaration in a visible part\v803. \u- W -\n \uWait\n \vselective wait\v908. \vWIDTH (predefined attribute)\v315. \vWith clause\v1002. \vdetermining order of compilation\v1006. \vdetermining the implicit order of library units\v806. \vin a context clause of a compilation unit\v1002. \vin a context clause of a subunit\v1004. \vinserted by the environment\v1007. \vleading to direct visibility\v803. \uWRITE (input-output procedure)\n \vin an instance of direct_io\v1406. \vin an instance of sequential_io\v1404. \vWriting an output file\v1401. \u- X -\n \uXor operator\n \vlogical operator\v411. \u- Y -\n \vYEAR (predefined function)\v906. 1. \uIntroduction\n Ada is a programming language designed in accordance with requirements defined by the United States Department of Defense: the so-called Steelman requirements. Overall, these requirements call for a language with considerable expressive power covering a wide application domain. As a result, the language includes facilities offered by classical languages such as Pascal as well as facilities often found only in specialized languages. Thus the language is a modern algorithmic language with the usual control structures, and with the ability to define types and subprograms. It also serves the need for modularity, whereby data, types, and subprograms can be packaged. It treats modularity in the physical sense as well, with a facility to support separate compilation. In addition to these aspects, the language covers real-time programming, with facilities to model parallel tasks and to handle exceptions. It also covers systems programming; this requires precise control over the representation of data and access to system-dependent properties. Finally, both application-level and machine-level input-output are defined. More details: 1.1 \vScope of the Standard\v101. 1.2 \vStructure of the Standard\v104. 1.3 \vDesign Goals and Sources\v105. 1.4 \vLanguage Summary\v106. 1.5 \vSyntax Notation\v107. 1.6 \vClassification of Errors\v108. 1.1 \uScope of the Standard\n This standard specifies the form and meaning of program units written in Ada. Its purpose is to promote the portability of Ada programs to a variety of data processing systems. More details: 1.1.1 \vExtent of the Standard\v102. 1.1.2 \vConformity of an Implementation with the Standard\v103. 1.1.1 \uExtent of the Standard\n This standard specifies: (a) The form of a program unit written in Ada. (b) The effect of translating and executing such a program unit. (c) The manner in which program units may be combined to form Ada programs. (d) The predefined program units that a conforming implementation must supply. (e) The permissible variations within the standard, and the manner in which they must be specified. (f) Those violations of the standard that a conforming implementation is required to detect, and the effect of attempting to translate or execute a program unit containing such violations. (g) Those violations of the standard that a conforming implementation is not required to detect. This standard does not specify: (h) The means whereby a program unit written in Ada is transformed into object code executable by a processor. (i) The means whereby translation or execution of program units is invoked and the executing units are controlled. (j) The size or speed of the object code, or the relative execution speed of different language constructs. (k) The form or contents of any listings produced by implementations; in particular, the form or contents of error or warning messages. (l) The effect of executing a program unit that contains any violation that a conforming implementation is not required to detect. (m) The size of a program or program unit that will exceed the capacity of a particular conforming implementation. Where this standard specifies that a program unit written in Ada has an exact effect, this effect is the operational meaning of the program unit and must be produced by all conforming implementations. Where this standard specifies permissible variations in the effects of constituents of a program unit written in Ada, the operational meaning of the program unit as a whole is understood to be the range of possible effects that result from all these variations, and a conforming implementation is allowed to produce any of these possible effects. Examples of permissible variations - The represented values of fixed or floating numeric quantities, and the results of operations upon them. - The order of execution of statements in different parallel tasks, in the absence of explicit synchronization. 1.1.2 \uConformity of an Implementation With the Standard\n A conforming implementation is one that: (a) Correctly translates and executes legal program units written in Ada, provided that they are not so large as to exceed the capacity of the implementation. (b) Rejects all program units that are so large as to exceed the capacity of the implementation. (c) Rejects all program units that contain errors whose detection is required by the standard. (d) Supplies all predefined program units required by the standard. (e) Contains no variations except where the standard permits. (f) Specifies all such permitted variations in the manner prescribed by the standard. 1.2 \uStructure of the Standard\n This reference manual contains fourteen chapters, three annexes, three appendices, and an index. Each chapter is divided into sections that have a common structure. Each section introduces its subject, gives any necessary syntax rules, and describes the semantics of the corresponding language constructs. Examples and notes, and then references, may appear at the end of a section. Examples are meant to illustrate the possible forms of the constructs described. Notes are meant to emphasize consequences of the rules described in the section or elsewhere. References are meant to attract the attention of readers to a term or phrase having a technical meaning defined in another section. The standard definition of the Ada programming language consists of the fourteen chapters and the three annexes, subject to the following restriction: the material in each of the items listed below is informative, and not part of the standard definition of the Ada programming language: - Section 1.3 \vDesign goals and sources\v105. - Section 1.4 \vLanguage summary\v106. - The examples, notes, and references given at the end of each section - Each section whose title starts with the word "Example" or "Examples" 1.3 \uDesign Goals and Sources\n Ada was designed with three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency. The need for languages that promote reliability and simplify maintenance is well established. Hence emphasis was placed on program readability over ease of writing. For example, the rules of the language require that program variables be explicitly declared and that their type be specified. Since the type of a variable is invariant, compilers can ensure that operations on variables are compatible with the properties intended for objects of the type. Furthermore, error-prone notations have been avoided, and the syntax of the language avoids the use of encoded forms in favor of more English-like constructs. Finally, the language offers support for separate compilation of program units in a way that facilitates program development and maintenance, and which provides the same degree of checking between units as within a unit. Concern for the human programmer was also stressed during the design. Above all, an attempt was made to keep the language as small as possible, given the ambitious nature of the application domain. We have attempted to cover this domain with a small number of underlying concepts integrated in a consistent and systematic way. Nevertheless we have tried to avoid the pitfalls of excessive involution, and in the constant search for simpler designs we have tried to provide language constructs that correspond intuitively to what the users will normally expect. Like many other human activities, the development of programs is becoming ever more decentralized and distributed. Consequently, the ability to assemble a program from independently produced software components has been a central idea in this design. The concepts of packages, of private types, and of generic units are directly related to this idea, which has ramifications in many other aspects of the language. No language can avoid the problem of efficiency. Languages that require over-elaborate compilers, or that lead to the inefficient use of storage or execution time, force these inefficiencies on all machines and on all programs. Every construct of the language was examined in the light of present implementation techniques. Any proposed construct whose implementation was unclear or that required excessive machine resources was rejected. None of the above design goals was considered as achievable after the fact. The design goals drove the entire design process from the beginning. A perpetual difficulty in language design is that one must both identify the capabilities required by the application domain and design language features that provide these capabilities. The difficulty existed in this design, although to a lesser degree than usual because of the Steelman requirements. These requirements often simplified the design process by allowing it to concentrate on the design of a given system providing a well defined set of capabilities, rather than on the definition of the capabilities themselves. Another significant simplification of the design work resulted from earlier experience acquired by several successful Pascal derivatives developed with similar goals. These are the languages Euclid, Lis, Mesa, Modula, and Sue. Many of the key ideas and syntactic forms developed in these languages have counterparts in Ada. Several existing languages such as Algol 68 and Simula, and also recent research languages such as Alphard and Clu, influenced this language in several respects, although to a lesser degree than did the Pascal family. Finally, the evaluation reports received on an earlier formulation (the Green language), and on alternative proposals (the Red, Blue, and Yellow languages), the language reviews that took place at different stages of this project, and the thousands of comments received from fifteen different countries during the preliminary stages of the Ada design and during the ANSI canvass, all had a significant impact on the standard definition of the language. 1.4 \uLanguage Summary\n An Ada program is composed of one or more program units. These program units can be compiled separately. Program units may be subprograms (which define executable algorithms), package units (which define collections of entities), task units (which define parallel computations), or generic units (which define parameterized forms of packages and subprograms). Each unit normally consists of two parts: a specification, containing the information that must be visible to other units, and a body, containing the implementation details, which need not be visible to other units. This distinction of the specification and body, and the ability to compile units separately, allows a program to be designed, written, and tested as a set of largely independent software components. An Ada program will normally make use of a library of program units of general utility. The language provides means whereby individual organizations can construct their own libraries. The text of a separately compiled program unit must name the library units it requires. \uProgram Units\n A subprogram is the basic unit for expressing an algorithm. There are two kinds of subprograms: procedures and functions. A procedure is the means of invoking a series of actions. For example, it may read data, update variables, or produce some output. It may have parameters, to provide a controlled means of passing information between the procedure and the point of call. A function is the means of invoking the computation of a value. It is similar to a procedure, but in addition will return a result. A package is the basic unit for defining a collection of logically related entities. For example, a package can be used to define a common pool of data and types, a collection of related subprograms, or a set of type declarations and associated operations. Portions of a package can be hidden from the user, thus allowing access only to the logical properties expressed by the package specification. A task unit is the basic unit for defining a task whose sequence of actions may be executed in parallel with those of other tasks. Such tasks may be implemented on multicomputers, multiprocessors, or with interleaved execution on a single processor. A task unit may define either a single executing task or a task type permitting the creation of any number of similar tasks. \uDeclarations and Statements\n The body of a program unit generally contains two parts: a declarative part, which defines the logical entities to be used in the program unit, and a sequence of statements, which defines the execution of the program unit. The declarative part associates names with declared entities. For example, a name may denote a type, a constant, a variable, or an exception. A declarative part also introduces the names and parameters of other nested subprograms, packages, task units, and generic units to be used in the program unit. The sequence of statements describes a sequence of actions that are to be performed. The statements are executed in succession (unless an exit, return, or goto statement, or the raising of an exception, causes execution to continue from another place). An assignment statement changes the value of a variable. A procedure call invokes execution of a procedure after associating any actual parameters provided at the call with the corresponding formal parameters. Case statements and if statements allow the selection of an enclosed sequence of statements based on the value of an expression or on the value of a condition. The loop statement provides the basic iterative mechanism in the language. A loop statement specifies that a sequence of statements is to be executed repeatedly as directed by an iteration scheme, or until an exit statement is encountered. A block statement comprises a sequence of statements preceded by the declaration of local entities used by the statements. Certain statements are only applicable to tasks. A delay statement delays the execution of a task for a specified duration. An entry call statement is written as a procedure call statement; it specifies that the task issuing the call is ready for a rendezvous with another task that has this entry. The called task is ready to accept the entry call when its execution reaches a corresponding accept statement, which specifies the actions then to be performed. After completion of the rendezvous, both the calling task and the task having the entry may continue their execution in parallel. One form of the select statement allows a selective wait for one of several alternative rendezvous. Other forms of the select statement allow conditional or timed entry calls. Execution of a program unit may encounter error situations in which normal program execution cannot continue. For example, an arithmetic computation may exceed the maximum allowed value of a number, or an attempt may be made to access an array component by using an incorrect index value. To deal with such error situations, the statements of a program unit can be textually followed by exception handlers that specify the actions to be taken when the error situation arises. Exceptions can be raised explicitly by a raise statement. \uData Types\n Every object in the language has a type, which characterizes a set of values and a set of applicable operations. The main classes of types are scalar types (comprising enumeration and numeric types), composite types, access types, and private types. An enumeration type defines an ordered set of distinct enumeration literals, for example a list of states or an alphabet of characters. The enumeration types BOOLEAN and CHARACTER are predefined. Numeric types provide a means of performing exact or approximate numerical computations. Exact computations use integer types, which denote sets of consecutive integers. Approximate computations use either fixed point types, with absolute bounds on the error, or floating point types, with relative bounds on the error. The numeric types INTEGER, FLOAT, and DURATION are predefined. Composite types allow definitions of structured objects with related components. The composite types in the language provide for arrays and records. An array is an object with indexed components of the same type. A record is an object with named components of possibly different types. The array type STRING is predefined. A record may have special components called discriminants. Alternative record structures that depend on the values of discriminants can be defined within a record type. Access types allow the construction of linked data structures created by the evaluation of allocators. They allow several variables of an access type to designate the same object, and components of one object to designate the same or other objects. Both the elements in such a linked data structure and their relation to other elements can be altered during program execution. Private types can be defined in a package that conceals structural details that are externally irrelevant. Only the logically necessary properties (including any discriminants) are made visible to the users of such types. The concept of a type is refined by the concept of a subtype, whereby a user can constrain the set of allowed values of a type. Subtypes can be used to define subranges of scalar types, arrays with a limited set of index values, and records and private types with particular discriminant values. \uOther Facilities\n Representation clauses can be used to specify the mapping between types and features of an underlying machine. For example, the user can specify that objects of a given type must be represented with a given number of bits, or that the components of a record are to be represented using a given storage layout. Other features allow the controlled use of low level, nonportable, or implementation-dependent aspects, including the direct insertion of machine code. Input-output is defined in the language by means of predefined library packages. Facilities are provided for input-output of values of user-defined as well as of predefined types. Standard means of representing values in display form are also provided. Finally, the language provides a powerful means of parameterization of program units, called generic program units. The generic parameters can be types and subprograms (as well as objects) and so allow general algorithms to be applied to all types of a given class. 1.5 \uMethod of Description and Syntax Notation\n The form of Ada program units is described by means of a context-free syntax together with context-dependent requirements expressed by narrative rules. The meaning of Ada program units is described by means of narrative rules defining both the effects of each construct and the composition rules for constructs. This narrative employs technical terms whose precise definition is given in the text (references to the section containing the definition of a technical term appear at the end of each section that uses the term). All other terms are in the English language and bear their natural meaning, as defined in Webster's Third New International Dictionary of the English Language. The context-free syntax of the language is described using a simple variant of Backus-Naur-Form. In particular, (a) Lower case words, some containing embedded underlines, are used to denote syntactic categories, for example: adding_operator Whenever the name of a syntactic category is used apart from the syntax rules themselves, spaces take the place of the underlines (thus: adding operator). (b) Boldface words are used to denote reserved words, for example: \uarray\n (c) Square brackets enclose optional items. Thus the two following rules are equivalent. return_statement ::= \ureturn\n [expression]; return_statement ::= \ureturn\n; | \ureturn\n expression; (d) Braces enclose a repeated item. The item may appear zero or more times; the repetitions occur from left to right as with an equivalent left-recursive rule. Thus the two following rules are equivalent. term ::= factor {multiplying_operator factor} term ::= factor | term multiplying_operator factor (e) A vertical bar separates alternative items unless it occurs immediately after an opening brace, in which case it stands for itself: letter_or_digit ::= letter | digit component_association ::= [choice {| choice} =>] expression (f) If the name of any syntactic category starts with an italicized part, it is equivalent to the category name without the italicized part. The italicized part is intended to convey some semantic information. For example type_name and task_name are both equivalent to name alone. Note: The syntax rules describing structured constructs are presented in a form that corresponds to the recommended paragraphing. For example, an if statement is defined as if_statement ::= \uif\n condition \uthen\n sequence_of_statements {\uelsif\n condition \uthen\n sequence_of_statements} [\uelse\n sequence_of_statements] \uend if\n; Different lines are used for parts of a syntax rule if the corresponding parts of the construct described by the rule are intended to be on different lines. Indentation in the rule is a recommendation for indentation of the corresponding part of the construct. It is recommended that all indentations be by multiples of a basic step of indentation (the number of spaces for the basic step is not defined). The preferred places for other line breaks are after semicolons. On the other hand, if a complete construct can fit on one line, this is also allowed in the recommended paragraphing. 1.6 \uClassification of Errors\n The language definition classifies errors into several different categories: (a) Errors that must be detected at compilation time by every Ada compiler. These errors correspond to any violation of a rule given in this reference manual, other than the violations that correspond to (b) or (c) below. In particular, violation of any rule that uses the terms must, allowed, legal, or illegal belongs to this category. Any program that contains such an error is not a legal Ada program; on the other hand, the fact that a program is legal does not mean, per se, that the program is free from other forms of error. (b) Errors that must be detected at run time by the execution of an Ada program. The corresponding error situations are associated with the names of the predefined exceptions. Every Ada compiler is required to generate code that raises the corresponding exception if such an error situation arises during program execution. If an exception is certain to be raised in every execution of a program, then compilers are allowed (although not required) to report this fact at compilation time. (c) Erroneous execution. The language rules specify certain rules to be obeyed by Ada programs, although there is no requirement on Ada compilers to provide either a compilation-time or a run-time detection of the violation of such rules. The errors of this category are indicated by the use of the word erroneous to qualify the execution of the corresponding constructs. The effect of erroneous execution is unpredictable. (d) Incorrect order dependences. Whenever the reference manual specifies that different parts of a given construct are to be executed in some order that is not defined by the language, this means that the implementation is allowed to execute these parts in any given order, following the rules that result from that given order, but not in parallel. Furthermore, the construct is incorrect if execution of these parts in a different order would have a different effect. Compilers are not required to provide either compilation-time or run-time detection of incorrect order dependences. The foregoing is expressed in terms of the process that is called execution; it applies equally to the processes that are called evaluation and elaboration. If a compiler is able to recognize at compilation time that a construct is erroneous or contains an incorrect order dependence, then the compiler is allowed to generate, in place of the code otherwise generated for the construct, code that raises the predefined exception PROGRAM_ERROR. Similarly, compilers are allowed to generate code that checks at run time for erroneous constructs, for incorrect order dependences, or for both. The predefined exception PROGRAM_ERROR is raised if such a check fails. 2. \uLexical Elements\n The text of a program consists of the texts of one or more compilations. The text of a \vcompilation\v1001. is a sequence of \vlexical elements\v202., each composed of \vcharacters\v201.; the rules of composition are given in this chapter. \vPragmas\v210., which provide certain information for the compiler, are also described in this chapter. More details: 2.1 \vCharacter Set\v201. 2.2 \vLexical Elements, Separators and Delimiters\v202. 2.3 \vIdentifiers\v203. 2.4 \vNumeric Literals\v204. 2.5 \vCharacter Literals\v207. 2.6 \vString Literals\v208. 2.7 \vComments\v209. 2.8 \vPragmas\v210. 2.9 \vReserved Words\v211. 2.10 \vAllowed Replacements of Characters\v212. 2.1 \uCharacter Set\n The only characters allowed in the text of a program are the graphic characters and format effectors. Each graphic character corresponds to a unique code of the ISO seven-bit coded character set (ISO standard 646), and is represented (visually) by a graphical symbol. Some graphic characters are represented by different graphical symbols in alternative national representations of the ISO character set. The description of the language definition in this standard reference manual uses the ASCII graphical symbols, the ANSI graphical representation of the ISO character graphic_character ::= basic_graphic_character | lower_case_letter | other_special_character basic_graphic_character ::= upper_case_letter | digit | special_character | space_character basic_character ::= basic_graphic_character | format_effector The basic character set is sufficient for writing any program. The characters included in each of the categories of basic graphic characters are defined as follows: (a) upper case letters A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (b) digits 0 1 2 3 4 5 6 7 8 9 (c) special characters " # & ' ( ) * + , - . / : ; < = > _ | (d) the space character Format effectors are the ISO (and ASCII) characters called horizontal tabulation, vertical tabulation, carriage return, line feed, and form feed. The characters included in each of the remaining categories of graphic characters are defined as follows: (e) lower case letters a b c d e f g h i j k l m n o p q r s t u v w x y z (f) other special characters ! $ % ? @ [ \\ ] ^ ` { } ~ Allowable replacements for the special characters vertical bar (|), sharp (#), and quotation (") are defined in section 2.10. \uNotes:\n The ISO character that corresponds to the sharp graphical symbol in the ASCII representation appears as a pound sterling symbol in the French, German, and United Kingdom standard national representations. In any case, the font design of graphical symbols (for example, whether they are in italic or bold typeface) is not part of the ISO standard. The meanings of the acronyms used in this section are as follows: ANSI stands for American National Standards Institute, ASCII stands for American Standard Code for Information Interchange, and ISO stands for International Organization for Standardization. The following names are used when referring to special characters and other special characters: symbol name symbol name " quotation > greater than # sharp _ underline & ampersand | vertical bar ' apostrophe ! exclamation mark ( left parenthesis $ dollar ) right parenthesis % percent * star, multiply ? question mark + plus @ commercial at , comma [ left square bracket - hyphen, minus \\ back-slash . dot, point, period ] right square bracket / slash, divide ^ circumflex : colon ` grave accent ; semicolon { left brace < less than } right brace = equal ~ tilde 2.2 \uLexical Elements, Separators, and Delimiters\n The text of a program consists of the texts of one or more compilations. The text of each \vcompilation\v1001. is a sequence of separate lexical elements. Each lexical element is either a delimiter, an \videntifier\v203. (which may be a \vreserved word\v211.), a \vnumeric literal\v204., a \vcharacter literal\v207., a \vstring literal\v208., or a \vcomment\v209.. The effect of a program depends only on the particular sequences of lexical elements that form its compilations, excluding the comments, if any. In some cases an explicit separator is required to separate adjacent lexical elements (namely, when without separation, interpretation as a single lexical element is possible). A separator is any of a space character, a \vformat effector\v201., or the end of a line. A \vspace character\v201. is a separator except within a comment, a string literal, or a space character literal. Format effectors other than horizontal tabulation are always separators. Horizontal tabulation is a separator except within a comment. The end of a line is always a separator. The language does not define what causes the end of a line. However if, for a given implementation, the end of a line is signified by one or more characters, then these characters must be format effectors other than horizontal tabulation. In any case, a sequence of one or more format effectors other than horizontal tabulation must cause at least one end of line. One or more separators are allowed between any two adjacent lexical elements, before the first of each compilation, or after the last. At least one separator is required between an identifier or a numeric literal and an adjacent identifier or numeric literal. A delimiter is either one of the following \vspecial characters\v201. (in the basic character set) & ' ( ) * + , - . / : ; < = > | or one of the following compound delimiters each composed of two adjacent special characters => .. ** := /= >= <= << >> <> Each of the special characters listed for single character delimiters is a single delimiter except if this character is used as a character of a compound delimiter, or as a character of a comment, string literal, character literal, or numeric literal. The remaining forms of lexical element are described in other sections of this chapter. \uNotes:\n Each lexical element must fit on one line, since the end of a line is a separator. The quotation, sharp, and underline characters, likewise two adjacent hyphens, are not delimiters, but may form part of other lexical elements. The following names are used when referring to compound delimiters: delimiter name => arrow .. double dot ** double star, exponentiate := assignment (pronounced: "becomes") /= inequality (pronounced: "not equal") >= greater than or equal <= less than or equal << left label bracket >> right label bracket <> box 2.3 \uIdentifiers\n Identifiers are used as \vnames\v401. and also as \vreserved words\v211.. identifier ::= letter {[underline] letter_or_digit} letter_or_digit ::= letter | digit letter ::= upper_case_letter | lower_case_letter All characters of an identifier are significant, including any underline character inserted between a letter or \vdigit\v201. and an adjacent letter or digit. Identifiers differing only in the use of corresponding upper and \vlower case letters\v201. are considered as the same. \uExamples:\n COUNT X get_symbol Ethelyn Marion SNOBOL_4 X1 PageCount STORE_NEXT_ITEM Note: No space is allowed within an identifier since a \vspace\v201. is a \vseparator\v202.. 2.4 \uNumeric Literals\n There are two classes of numeric \vliterals\v406.: real literals and integer literals. A real literal is a numeric literal that includes a point; an integer literal is a numeric literal without a point. Real literals are the literals of the type \vuniversal_real\v316.. Integer literals are the literals of the type \vuniversal_integer\v314.. numeric_literal ::= decimal_literal | based_literal More details: 2.4.1 \vDecimal Literals\v205. 2.4.2 \vBased Literals\v206. 2.4.1 \uDecimal Literals\n A decimal literal is a numeric literal expressed in the conventional decimal notation (that is, the base is implicitly ten). decimal_literal ::= integer [.integer] [exponent] integer ::= digit {[underline] digit} exponent ::= E [+] integer | E - integer An underline character inserted between adjacent \vdigits\v201. of a decimal literal does not affect the value of this \vnumeric literal\v204.. The letter E of the exponent, if any, can be written either in \vlower case\v201. or in upper case, with the same meaning. An exponent indicates the power of ten by which the value of the decimal literal without the exponent is to be multiplied to obtain the value of the decimal literal with the exponent. An exponent for an integer literal must not have a minus sign. \uExamples:\n 12 0 1E6 123_456 -- integer literals 12.0 0.0 0.456 3.14159_26 -- real literals 1.34E-12 1.0E+6 -- real literals with exponent \uNotes:\n Leading zeros are allowed. No space is allowed in a numeric literal, not even between constituents of the exponent, since a \vspace\v201. is a \vseparator\v202.. A zero exponent is allowed for an integer literal. 2.4.2 \uBased Literals\n A based literal is a \vnumeric literal\v204. expressed in a form that specifies the base explicitly. The base must be at least two and at most sixteen. based_literal ::= base # based_integer [.based_integer] # [exponent] base ::= integer based_integer ::= extended_digit {[underline] extended_digit} extended_digit ::= digit | letter An underline character inserted between adjacent \vdigits\v201. of a based literal does not affect the value of this numeric literal. The base and the \vexponent\v205., if any, are in decimal notation. The only \vletters\v203. allowed as extended digits are the letters A through F for the digits ten through fifteen. A letter in a based literal (either an extended digit or the letter E of an exponent) can be written either in \vlower\v201. case or in \vupper\v201. case, with the same meaning. The conventional meaning of based notation is assumed; in particular the value of each extended digit of a based literal must be less than the base. An exponent indicates the power of the base by which the value of the based literal without the exponent is to be multiplied to obtain the value of the based literal with the exponent. \uExamples:\n 2#1111_1111# 16#FF# 016#0FF# -- integer literals of value 255 16#E#E1 2#1110_0000 # -- integer literals of value 224 16#F.FF#E+2 2#1.1111_1111_111#E11 -- real literals of value 4095.0 2.5 \uCharacter Literals\n A character \vliteral\v406. is formed by enclosing one of the 95 \vgraphic\v201. characters (including the \vspace\v201.) between two apostrophe characters. A character has a value that belongs to a \vcharacter type\v312.. character_literal ::= 'graphic_character' \uExamples:\n 'A' '*' ''' ' ' 2.6 \uString Literals\n A string literal is formed by a sequence of \vgraphic characters\v201. (possibly none) enclosed between two quotation characters used as string brackets. string_literal ::= "{graphic_character}" A string literal has a value that is a sequence of \vcharacter values\v312. corresponding to the graphic characters of the string literal apart from the quotation character itself. If a quotation character value is to be represented in the sequence of character values, then a pair of adjacent quotation characters must be written at the corresponding place within the string literal. (This means that a string literal that includes two adjacent quotation characters is never interpreted as two adjacent string literals.) The length of a string literal is the number of character values in the sequence represented. (Each doubled quotation character is counted as a single character.) \uExamples:\n "Message of the day:" "" -- an empty string literal " " "A" """" -- three string literals of length 1 "Characters such as $, %, and } are allowed in string literals" Note: A string literal must fit on one line since it is a \vlexical element\v202. (see 2.2). Longer sequences of graphic character values can be obtained by \vcatenation\v414. of string literals. Similarly catenation of \vconstants\v303. \vdeclared\v301. in the package ASCII can be used to obtain sequences of character values that include nongraphic character values (the so-called control characters). Examples of such uses of catenation are given below: "FIRST PART OF A SEQUENCE OF CHARACTERS " & "THAT CONTINUES ON THE NEXT LINE" "sequence that includes the" & ASCII.ACK & "control character" 2.7 \uComments\n A comment starts with two adjacent hyphens and extends up to the \vend of the\v202. \vline\v202.. A comment can appear on any line of a program. The presence or absence of comments has no influence on whether a program is \vlegal\v108. or \villegal\v108.. Furthermore, comments do not influence the effect of a program; their sole purpose is the enlightenment of the human reader. \uExamples:\n -- the last sentence above echoes the Algol 68 report \uend\n; -- processing of LINE is complete -- a long comment may be split onto -- two or more consecutive lines ---------------- the first two hyphens start the comment Note: Horizontal tabulation can be used in comments, after the double hyphen, and is equivalent to one or more \vspaces\v201. (see 2.2). 2.8 \uPragmas\n A pragma is used to convey information to the \vcompiler\v1001.. A pragma starts with the \vreserved word\v211. pragma followed by an identifier that is the name of the pragma. \upragma\n ::= \upragma\n \videntifier\v203. [(argument_association {, argument_association})]; argument_association ::= [argument_identifier =>] \vname\v401. | [argument_identifier =>] \vexpression\v410. Pragmas are only allowed at the following places in a program: - After a semicolon \vdelimiter\v202., but not within a \vformal part\v601. or \vdiscriminant part\v326.. - At any place where the syntax rules allow a construct defined by a syntactic category whose name ends with "declaration", "\vstatement\v500.", "clause", or "alternative", or one of the syntactic categories \vvariant\v328. and \vexception handler\v1102.; but not in place of such a construct. Also at any place where a compilation unit would be allowed. Additional restrictions exist for the placement of specific pragmas. Some pragmas have arguments. Argument associations can be either positional or named as for parameter associations of subprogram calls (see 6.4). Named associations are, however, only possible if the argument identifiers are defined. A name given in an argument must be either a name \vvisible\v803. at the place of the pragma or an identifier specific to the pragma. The pragmas defined by the language are described in Annex B: they must be supported by every implementation. In addition, an implementation may provide \vimplementation-defined pragmas\v2000., which must then be described in Appendix F. An implementation is not allowed to define pragmas whose presence or absence influences the \vlegality\v108. of the text outside such pragmas. Consequently, the legality of a program does not depend on the presence or absence of implementation-defined pragmas. A pragma that is not \vlanguage-defined\v1600. has no effect if its identifier is not recognized by the (current) implementation. Furthermore, a pragma (whether language-defined or implementation-defined) has no effect if its placement or its arguments do not correspond to what is allowed for the pragma. The region of text over which a pragma has an effect depends on the pragma. \uExamples:\n \upragma\n LIST(OFF); \upragma\n OPTIMIZE(TIME); \upragma\n INLINE(SETMASK); \upragma\n SUPPRESS(RANGE_CHECK, ON => INDEX); Note: It is recommended (but not required) that implementations issue warnings for pragmas that are not recognized and therefore ignored. 2.9 \uReserved Words\n The \videntifiers\v203. listed below are called reserved words and are reserved for special significance in the language. For readability of this manual, the reserved words appear in \vlower case\v201. boldface. \uabort declare generic of select\n \uabs delay goto or separate\n \uaccept delta others subtype\n \uaccess digits if out\n \uall do in task\n \uand is package terminate\n \uarray pragma then\n \uat else private type\n \uelsif limited procedure\n \uend loop\n \ubegin entry raise use\n \ubody exception range\n \uexit mod record when\n \urem while\n \unew renames with\n \ucase for not return\n \uconstant function null reverse xor\n A reserved word must not be used as a declared identifier. \uNotes:\n Reserved words differing only in the use of corresponding upper and lower case letters are considered as the same (see 2.3). In some \vattributes\v405. the identifier that appears after the apostrophe is identical to some reserved word. 2.10 \uAllowable Replacements of Characters\n The following replacements are allowed for the vertical bar, sharp, and quotation \vbasic characters\v201.: - A vertical bar character (|) can be replaced by an exclamation mark (!) where used as a \vdelimiter\v202.. - The sharp characters (#) of a \vbased literal\v206. can be replaced by colons (:) provided that the replacement is done for both occurrences. - The quotation characters (") used as \vstring brackets\v208. at both ends of a \vstring literal\v208. can be replaced by percent characters (%) provided that the enclosed sequence of characters contains no quotation character, and provided that both string brackets are replaced. Any percent character within the sequence of characters must then be doubled and each such doubled percent character is interpreted as a single percent \vcharacter value\v312.. These replacements do not change the meaning of the program. \uNotes:\n It is recommended that use of the replacements for the vertical bar, sharp, and quotation characters be restricted to cases where the corresponding \vgraphical symbols\v201. are not available. Note that the vertical bar appears as a broken bar on some equipment; replacement is not recommended in this case. The rules given for \videntifiers\v203. and \vnumeric literals\v204. are such that \vlower\v201. \vcase and upper case\v201. letters can be used indifferently; these \vlexical\v202. \velements\v202. can thus be written using only characters of the basic character set. If a string literal of the predefined type STRING contains characters that are not in the basic character set, the same sequence of character values can be obtained by \vcatenating\v414. string literals that contain only characters of the basic character set with suitable character constants declared in the \vpredefined package ASCII\v1700.. Thus the string literal "AB$CD" could be replaced by "AB" & ASCII.DOLLAR & "CD". Similarly, the string literal "ABcd" with lower case letters could be replaced by "AB" & ASCII.LC_C & ASCII.LC_D. 3. \uDeclarations and Types\n This chapter describes the types in the language and the rules for declaring constants, variables, and named numbers. 3.1 \vDeclarations\v301. 3.2 \vObjects and Named Numbers\v302. 3.3 \vTypes and Subtypes\v305. 3.4 \vDerived Types\v309. 3.5 \vScalar Types\v310. 3.6 \vArray Types\v321. 3.7 \vRecord Types\v325. 3.8 \vAccess Types\v330. 3.9 \vDeclarative Parts\v333. 3.1 \uDeclarations\n The language defines several kinds of entities that are declared, either explicitly or implicitly, by declarations. Such an entity can be a \vnumeric\v204. \vliteral\v204., an object, a discriminant, a \vrecord component\v325., a loop parameter, an exception, a type, a subtype, a subprogram, a package, a task unit, a generic unit, a single entry, an entry family, a formal parameter (of a subprogram, entry, or \vgeneric subprogram\v1201.), a generic formal parameter, a named block or loop, a labeled statement, or an \voperation\v305. (in particular, an \vattribute\v405. or an enumeration literal; see 3.3.3). There are several forms of declaration. A basic declaration is a form of declaration defined as follows. basic_declaration ::= \vobject_declaration\v303. | \vnumber_declaration\v304. | \vtype_declaration\v306. | subtype_declaration | subprogram_declaration | \vpackage_declaration\v701. | task_declaration | generic_declaration | exception_declaration | generic_instantiation | \vrenaming_declaration\v805. | deferred_constant_declaration Certain forms of declaration always occur (explicitly) as part of a basic declaration; these forms are \vdiscriminant specifications\v326., \vcomponent\v325. \vdeclarations\v325., \ventry declarations\v905., \vparameter specifications\v601., \vgeneric\v1201. \vparameter declarations\v1201., and \venumeration literal specifications\v311.. A \vloop\v506. \vparameter specification\v506. is a form of declaration that occurs only in certain forms of loop statement. The remaining forms of declaration are implicit: the \vname\v401. of a block, the name of a loop, and a statement label are implicitly declared. Certain operations are implicitly declared (see 3.3.3). For each form of declaration the language rules define a certain region of text called the \vscope\v802. of the declaration (see 8.2). Several forms of declaration associate an \videntifier\v203. with a declared entity. Within its scope, and only there, there are places where it is possible to use the identifier to refer to the associated declared entity; these places are defined by the \vvisibility\v803. rules (see 8.3). At such places the identifier is said to be a name of the entity (its \vsimple name\v401.); the name is said to denote the associated entity. Certain forms of enumeration literal specification associate a \vcharacter\v207. \vliteral\v207. with the corresponding declared entity. Certain forms of declaration associate an \voperator symbol\v601. or some other notation with an explicitly or implicitly declared operation. The process by which a declaration achieves its effect is called the \velaboration\v333. of the declaration; this process happens during program execution. After its elaboration, a declaration is said to be elaborated. Prior to the completion of its elaboration (including before the elaboration), the declaration is not yet elaborated. The elaboration of any declaration has always at least the effect of achieving this change of state (from not yet elaborated to elaborated). The phrase "the elaboration has no other effect" is used in this manual whenever this change of state is the only effect of elaboration for some form of declaration. An elaboration process is also defined for \vdeclarative parts\v333., \vdeclarative items\v333., and compilation units (see 3.9 and 10.5). Object, number, type, and \vsubtype declarations\v307. are described here. The remaining basic declarations are described in later chapters. Note: The syntax rules use the term identifier for the first occurrence of an identifier in some form of declaration; the term simple name is used for any occurrence of an identifier that already denotes some declared entity. 3.2 \uObjects and Named Numbers\n An object is an entity that contains (has) a value of a given \vtype\v305.. An object is one of the following: - an object declared by an object \vdeclaration\v301. or by a \vsingle\v901. \vtask declaration\v901., - a \vformal parameter\v601. of a \vsubprogram\v600., \ventry\v905., or \vgeneric subprogram\v1201., - a generic formal object, - a \vloop parameter\v506., - an object \vdesignated\v330. by a value of an \vaccess type\v330., - a \vcomponent\v305. or a \vslice\v403. of another object. A number declaration is a special form of object declaration that associates an identifier with a value of \vtype\v305. \vuniversal_integer\v314. or \vuniversal_real\v316. object_declaration ::= identifier_list : [\uconstant\n] \vsubtype_indication\v307. [:= \vexpression\v410.]; | identifier_list : [\uconstant\n] \vconstrained_array_definition\v321. [:= expression]; number_declaration ::= identifier_list : \uconstant\n := universal_static_expression; identifier_list ::= identifier {, identifier} An object declaration is called a single object declaration if its identifier list has a single identifier; it is called a multiple object declaration if the identifier list has two or more identifiers. A multiple object declaration is equivalent to a sequence of the corresponding number of single object declarations. For each identifier of the list, the equivalent sequence has a single object declaration formed by this identifier, followed by a colon and by whatever appears at the right of the colon in the multiple object declaration; the equivalent sequence is in the same order as the identifier list. A similar equivalence applies also for the identifier lists of number declarations, component declarations, \vdiscriminant\v326. \vspecifications\v326., parameter specifications, generic parameter declarations, \vexception\v1101. \vdeclarations\v1101., and \vdeferred constant declarations\v704.. In the remainder of this reference manual, explanations are given for declarations with a single identifier; the corresponding explanations for declarations with several identifiers follow from the equivalence stated above. Example: -- the multiple object declaration JOHN, PAUL : PERSON_NAME := new PERSON(SEX => M); -- see 3.8.1 -- is equivalent to the two single object declarations in the order given JOHN : PERSON_NAME := \unew\n PERSON(SEX => M); PAUL : PERSON_NAME := \unew\n PERSON(SEX => M); More details: 3.2.1 \vObject Declarations\v303. 3.2.2 \vNumber Declarations\v304. 3.2.1 \uObject Declarations\n An object \vdeclaration\v301. declares an object whose \vtype\v305. is given either by a \vsubtype\v305. indication or by a \vconstrained array definition\v321.. If the object declaration includes the \vassignment compound delimiter\v502. followed by an \vexpression\v410., the expression specifies an initial value for the declared object; the type of the expression must be that of the object. The declared object is a constant if the \vreserved word\v211. constant appears in the object declaration; the declaration must then include an explicit initialization. The value of a constant cannot be modified after initialization. Formal parameters of \vmode in\v601. of \vsubprograms\v600. and entries, and \vgeneric formal parameters\v1201. of mode in, are also constants; a loop parameter is a constant within the corresponding loop; a \vsubcomponent\v305. or \vslice\v403. of a constant is a constant. An object that is not a constant is called a variable (in particular, the object declared by an object declaration that does not include the reserved word constant is a variable). The only ways to change the value of a variable are either directly by an \vassignment\v502., or indirectly when the variable is updated (see 6.2) by a procedure or \ventry\v905. call statement (this action can be performed either on the variable itself, on a subcomponent of the variable, or on another variable that has the given variable as subcomponent). The \velaboration\v333. of an object declaration proceeds as follows: (a) The \vsubtype indication\v307. or the constrained array definition is first elaborated. This establishes the subtype of the object. (b) If the object declaration includes an explicit initialization, the initial value is obtained by evaluating the corresponding expression. Otherwise any implicit initial values for the object or for its subcomponents are evaluated. (c) The object is created. (d) Any initial value (whether explicit or implicit) is assigned to the object or to the corresponding subcomponent. Implicit initial values are defined for objects declared by object declarations, and for components of such objects, in the following cases: - If the type of an object is an \vaccess type\v330., the implicit initial value is the null value of the access type. - If the type of an object is a \vtask type\v902., the implicit initial (and only) value \vdesignates\v330. a corresponding \vtask\v900.. - If the type of an object is a type with discriminants and the subtype of the object is constrained, the implicit initial (and only) value of each \vdiscriminant\v305. is defined by the subtype of the object. - If the type of an object is a composite type, the implicit initial value of each \vcomponent\v305. that has a default expression is obtained by \vevaluation\v411. of this expression, unless the component is a discriminant of a constrained object (the previous case). In the case of a component that is itself a composite object and whose value is defined neither by an explicit initialization nor by a default expression, any implicit initial values for components of the composite object are defined by the same rules as for a declared object. The steps (a) to (d) are performed in the order indicated. For step (b), if the default expression for a discriminant is evaluated, then this evaluation is performed before that of default expressions for subcomponents that depend on discriminants, and also before that of default expressions that include the name of the discriminant. Apart from the previous rule, the evaluation of default expressions is performed \vin some\v108. \vorder\v108. that is not defined by the language. The initialization of an object (the declared object or one of its subcomponents) checks that the initial value belongs to the subtype of the object; for an array object declared by an object declaration, an implicit subtype \vconversion\v419. is first applied as for an assignment statement, unless the object is a constant whose subtype is an unconstrained array type. The \vexception CONSTRAINT_ERROR\v1101. is raised if this check fails. The value of a scalar variable is undefined after elaboration of the corresponding object declaration unless an initial value is assigned to the variable by an initialization (explicitly or implicitly). If the operand of a type conversion or \vqualified expression\v420. is a variable that has scalar subcomponents with undefined values, then the values of the corresponding subcomponents of the result are undefined. The execution of a program is erroneous if it attempts to evaluate a scalar variable with an undefined value. Similarly, the execution of a program is erroneous if it attempts to apply a \vpredefined operator\v411. to a variable that has a scalar subcomponent with an undefined value. Examples of variable declarations: COUNT, SUM : INTEGER; SIZE : INTEGER \urange\n 0 .. 10_ := 0; SORTED : BOOLEAN := FALSE; COLOR_TABLE : \uarray\n(1 .. N) \uof\n COLOR; OPTION : BIT_VECTOR(1 .. 10) := (others => TRUE); Examples of constant declarations: LIMIT : \uconstant\n INTEGER := 10_ LOW_LIMIT : \uconstant\n INTEGER := LIMIT/10; TOLERANCE : \uconstant\n REAL := DISPERSION(1.15); Note: The expression initializing a constant object need not be a static expression (see 4.9). In the above examples, LIMIT and LOW_LIMIT are initialized with static expressions, but TOLERANCE is not if DISPERSION is a user-defined function. 3.2.2 \uNumber Declarations\n A number declaration is a special form of constant declaration. The \vtype\v305. of the static expression given for the initialization of a number declaration must be either the type \vuniversal_integer\v314. or the type \vuniversal_real\v316.. The constant declared by a number declaration is called a named number and has the type of the \vstatic expression\v422.. Note: The rules concerning expressions of a \vuniversal type\v405. are explained in section 4.10. It is a consequence of these rules that if every \vprimary\v410. contained in the expression is of the type universal_integer, then the named number is also of this type. Similarly, if every primary is of the type universal_real, then the named number is also of this type. Examples of number declarations: PI : \uconstant\n := 3.14159_26536; -- a real number TWO_PI : \uconstant\n := 2.0*PI; -- a real number MAX : \uconstant\n := 5 -- an integer number POWER_16 : \uconstant\n := 2**16; -- the integer 65_536 ONE, UN, EINS : \uconstant\n := 1; -- three different names for 1 3.3 \uTypes and Subtypes\n A type is characterized by a set of values and a set of operations. There exist several classes of types. Scalar types are integer types, real types, and types defined by enumeration of their values; values of these types have no components. Array and \vrecord types\v325. are composite; a value of a composite type consists of component values. An \vaccess\v330. \vtype\v330. is a type whose values provide access to \vobjects\v303.. \vPrivate types\v704. are types for which the set of possible values is well defined, but not directly available to the users of such types. Finally, there are \vtask types\v901.. (Private types are described in chapter 7, task types are described in chapter 9, the other classes of types are described in this chapter.) Certain record and private types have special components called discriminants whose values distinguish alternative forms of values of one of these types. If a private type has discriminants, they are known to users of the type. Hence a private type is only known by its name, its discriminants if any, and by the corresponding set of operations. The set of possible values for an object of a given type can be subjected to a condition that is called a constraint (the case where the constraint imposes no restriction is also included); a value is said to satisfy a constraint if it satisfies the corresponding condition. A subtype is a type together with a constraint; a value is said to belong to a subtype of a given type if it belongs to the type and satisfies the constraint; the given type is called the base type of the subtype. A type is a subtype of itself; such a subtype is said to be unconstrained: it corresponds to a condition that imposes no restriction. The base type of a type is the type itself. The set of operations defined for a subtype of a given type includes the operations that are defined for the type; however the \vassignment\v502. operation to a variable having a given subtype only assigns values that belong to the subtype. Additional operations, such as qualification (in a qualified expression), are implicitly defined by a \vsubtype declaration\v307.. Certain types have default initial values defined for objects of the type; certain other types have default expressions defined for some or all of their components. Certain operations of types and subtypes are called \vattributes\v405.; these operations are denoted by the form of name described in section 4.1.4. The term subcomponent is used in this manual in place of the term component to indicate either a component, or a component of another component or subcomponent. Where other subcomponents are excluded, the term component is used instead. A given type must not have a subcomponent whose type is the given type itself. The name of a class of types is used in this manual as a qualifier for objects and values that have a type of the class considered. For example, the term "array object" is used for an object whose type is an \varray type\v321.; similarly, the term "access value" is used for a value of an access type. Note: The set of values of a subtype is a subset of the values of the base type. This subset need not be a proper subset; it can be an empty subset. More details: 3.3.1 \vType Declarations\v306. 3.3.2 \vSubtype Declarations\v307. 3.3.3 \vClassification of Operations\v308. 3.3.1 \uType Declarations\n A type \vdeclaration\v301. declares a \vtype\v305.. type_declaration ::= full_type_declaration | incomplete_type_declaration | private_type_declaration full_type_declaration ::= \utype\n \videntifier\v203. [discriminant_part] \uis\n type_definition; type_definition ::= \venumeration_type_definition\v311. | \vinteger_type_definition\v314. | \vreal_type_definition\v316. | array_type_definition | record_type_definition | access_type_definition | derived_type_definition The \velaboration\v333. of a full type declaration consists of the elaboration of the \vdiscriminant part\v326., if any (except in the case of the full type declaration for an incomplete or \vprivate type declaration\v704.), and of the elaboration of the type definition. The types created by the elaboration of distinct type definitions are distinct types. Moreover, the elaboration of the type definition for a \vnumeric\v310. or \vderived type\v309. creates both a \vbase type\v305. and a subtype of the base type; the same holds for a \vconstrained array definition\v321. (one of the two forms of \varray type definition\v321.). The simple name declared by a full type declaration denotes the declared type, unless the type declaration declares both a base type and a subtype of the base type, in which case the simple name denotes the subtype, and the base type is anonymous. A type is said to be anonymous if it has no simple name. For explanatory purposes, this reference manual sometimes refers to an anonymous type by a pseudo-name, written in italics, and uses such pseudo-names at places where the syntax normally requires an identifier. Examples of type definitions: (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK) range1 .. 72 \uarray\n(1 .. 10) \uof\n INTEGER Examples of type declarations: \utype\n COLOR \uis\n (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK); \utype\n COLUMN \uis range\n 1 .. 72; \utype\n TABLE \uis array\n(1 .. 10) \uof\n INTEGER; \uNotes:\n Two type definitions always define two distinct types, even if they are textually identical. Thus, the array type definitions given in the declarations of A and B below define distinct types. A : \uarray\n(1 .. 10) \uof\n BOOLEAN; B : \uarray\n(1 .. 10) \uof\n BOOLEAN; If A and B are declared by a \vmultiple object declaration\v302. as below, their types are nevertheless different, since the multiple object declaration is equivalent to the above two single object declarations. A, B : \uarray\n(1 .. 10) \uof\n BOOLEAN; \vIncomplete type declarations\v331. are used for the definition of recursive and mutually dependent types (see 3.8.1). Private type declarations are used in package specifications and in \vgeneric parameter declarations\v1201. (see 7.4 and 12.1). 3.3.2 \uSubtype Declarations\n A \vsubtype\v305. \vdeclaration\v301. declares a subtype. subtype_declaration ::= \usubtype\n identifier \uis\n subtype_indication; subtype_indication ::= type_mark [constraint] type_mark ::= type_name | subtype_name constraint ::= \vrange_constraint\v310. | \vfloating_point_constraint\v317. | fixed_point_constraint | \vindex_constraint\v322. | discriminant_constraint A \vtype\v305. mark denotes a type or a subtype. If a type mark is the name of a type, the type mark denotes this type and also the corresponding \vunconstrained subtype\v305.. The \vbase type\v305. of a type mark is, by definition, the base type of the type or subtype denoted by the type mark. A subtype indication defines a subtype of the base type of the type mark. If an index constraint appears after a type mark in a subtype indication, the type mark must not already impose an index constraint. Likewise for a \vdiscriminant constraint\v327., the type mark must not already impose a \vdiscriminant\v305. constraint. The \velaboration\v333. of a subtype declaration consists of the elaboration of the subtype indication. The elaboration of a subtype indication creates a subtype. If the subtype indication does not include a constraint, the subtype is the same as that denoted by the type mark. The elaboration of a subtype indication that includes a constraint proceeds as follows: (a) The constraint is first elaborated. (b) A check is then made that the constraint is compatible with the type or subtype denoted by the type mark. The condition imposed by a constraint is the condition obtained after elaboration of the constraint. (The rules of constraint elaboration are such that the \vexpressions\v410. and ranges of constraints are evaluated by the elaboration of these constraints.) The rules defining compatibility are given for each form of constraint in the appropriate section. These rules are such that if a constraint is compatible with a subtype, then the condition imposed by the constraint cannot contradict any condition already imposed by the subtype on its values. The exception \vCONSTRAINT_ERROR\v1100. is raised if any check of compatibility fails. Examples of subtype declarations: \usubtype\n RAINBOW \uis\n COLOR \urange\n RED .. BLUE; -- see 3.3.1 \usubtype\n RED_BLUE \uis\n RAINBOW; \usubtype\n INT \uis\n INTEGER; \usubtype\n SMALL_INT \uis\n INTEGER \urange\n -10 .. 10; \usubtype\n UP_TO_K \uis\n COLUMN \urange\n 1 .. K; -- see 3.3.1 \usubtype\n SQUARE \uis\n MATRIX(1 .. 10, 1 .. 10); -- see 3.6 \usubtype\n MALE \uis\n PERSON(SEX => M); -- see 3.8 Note: A subtype declaration does not define a new type. 3.3.3 \uClassification of Operations\n The set of operations of a \vtype\v305. includes the explicitly declared \vsubprograms\v600. that have a parameter or result of the type; such subprograms are necessarily declared after the \vtype declaration\v306.. The remaining operations are each implicitly declared for a given type declaration, immediately after the type definition. These implicitly declared operations comprise the basic operations, the \vpredefined\v411. \voperators\v411. (see 4.5), and \venumeration literals\v311.. In the case of a derived type declaration, the implicitly declared operations include any derived subprograms. The operations implicitly declared for a given type declaration occur after the type declaration and before the next explicit declaration, if any. The implicit declarations of \vderived\v309. \vsubprograms\v309. occur last. A basic operation is an operation that is inherent in one of the following: - An \vassignment\v502. (in assignment statements and initializations), an \vallocator\v421., a \vmembership test\v411., or a \vshort-circuit control form\v411.. - A \vselected component\v404., an \vindexed component\v402., or a \vslice\v403.. - A qualification (in \vqualified expressions\v420.), an explicit type \vconversion\v419., or an implicit type conversion of a value of type \vuniversal_integer\v314. or \vuniversal_real\v316. to the corresponding value of another \vnumeric type\v310.. - A numeric \vliteral\v406. (for a \vuniversal type\v405.), the \vliteral\v330. \unull\n (for an access type), a \vstring literal\v208., an \vaggregate\v407., or an \vattribute\v405.. For every type or \vsubtype\v305. T, the following attribute is defined: T'BASE The base type of T. This attribute is allowed only as the prefix of the name of another attribute: for example, T'BASE'FIRST. Note: Each literal is an operation whose evaluation yields the corresponding value (see 4.2). Likewise, an aggregate is an operation whose evaluation yields a value of a \vcomposite type\v305. (see 4.3). Some operations of a type operate on values of the type, for example, predefined operators and certain subprograms and attributes. The evaluation of some operations of a type returns a value of the type, for example, literals and certain \vfunctions\v609., attributes, and predefined operators. Assignment is an operation that operates on an \vobject\v303. and a value. The evaluation of the operation corresponding to a selected component, an indexed component, or a slice, yields the object or value denoted by this form of name. 3.4 \uDerived Types\n A derived type definition defines a new (base) type whose characteristics are derived from those of a parent type; the new type is called a derived type. A derived type definition further defines a derived \vsubtype\v305., which is a subtype of the derived \vtype\v305.. derived_type_definition ::= \unew\n \vsubtype_indication\v307. The subtype indication that occurs after the \vreserved word\v211. new defines the parent subtype. The parent type is the \vbase type\v305. of the parent subtype. If a \vconstraint\v305. exists for the parent subtype, a similar constraint exists for the derived subtype; the only difference is that for a \vrange\v310. \vconstraint\v310., and likewise for a \vfloating\v317. or \vfixed\v319. \vpoint constraint\v319. that includes a range constraint, the value of each bound is replaced by the corresponding value of the derived type. The characteristics of the derived type are defined as follows: - The derived type belongs to the same class of types as the parent type. The set of possible values for the derived type is a copy of the set of possible values for the parent type. If the parent type is composite, then the same components exist for the derived type, and the subtype of corresponding components is the same. - For each \vbasic operation\v308. of the parent type, there is a corresponding basic operation of the derived type. Explicit type conversion of a value of the parent type into the corresponding value of the derived type is allowed and vice versa as explained in section 4.6. - For each \venumeration literal\v311. or \vpredefined\v411. \voperator\v411. of the parent type there is a corresponding operation for the derived type. - If the parent type is a task type, then for each entry of the parent type there is a corresponding entry for the derived type. - If a \vdefault expression\v303. exists for a component of an object having the parent type, then the same default expression is used for the corresponding component of an object having the derived type. - If the parent type is an access type, then the parent and the derived type share the same \vcollection\v330.; there is a null \vaccess\v330. \vvalue\v330. for the derived type and it is the \vdefault initial value\v330. of that type. - If an explicit \vrepresentation clause\v1301. exists for the parent type and if this clause appears before the derived \vtype definition\v306., then there is a corresponding representation clause (an implicit one) for the derived type. - Certain \vsubprograms\v600. that are operations of the parent type are said to be derivable. For each derivable subprogram of the parent type, there is a corresponding derived subprogram for the derived type. Two kinds of derivable subprograms exist. First, if the parent type is declared \vimmediately within\v801. the \vvisible part\v702. of a \vpackage\v700., then a subprogram that is itself explicitly declared immediately within the visible part becomes derivable after the end of the visible part, if it is an operation of the parent type. (The explicit \vdeclaration\v301. is by a \vsubprogram declaration\v601., a \vrenaming declaration\v805., or a generic instantiation.) Second, if the parent type is itself a derived type, then any subprogram that has been derived by this parent type is further derivable, unless the parent type is declared in the visible part of a package and the derived subprogram is hidden by a derivable subprogram of the first kind. Each operation of the derived type is implicitly declared at the place of the derived type declaration. The \vimplicit declarations\v301. of any derived subprograms occur last. The specification of a derived subprogram is obtained implicitly by systematic replacement of the parent type by the derived type in the specification of the derivable subprogram. Any subtype of the parent type is likewise replaced by a subtype of the derived type with a similar constraint (as for the transformation of a constraint of the parent subtype into the corresponding constraint of the derived subtype). Finally, any expression of the parent type is made to be the operand of a type \vconversion\v419. that yields a result of the derived type. Calling a derived subprogram is equivalent to calling the corresponding subprogram of the parent type, in which each \vactual\v607. \vparameter\v607. that is of the derived type is replaced by a type conversion of this actual parameter to the parent type (this means that a conversion to the parent type happens before the call for the \vmodes\v601. in and in out; a reverse conversion to the derived type happens after the call for the modes in out and out, see 6.4.1). In addition, if the result of a called function is of the parent type, this result is converted to the derived type. If a derived or \vprivate type\v704. is declared immediately within the visible part of a package, then, within this visible part, this type must not be used as the parent type of a derived type definition. (For private types, see also section 7.4.1.) For the \velaboration\v333. of a derived type definition, the subtype indication is first elaborated, the derived type is then created, and finally, the derived subtype is created. \uExamples:\n \utype\n LOCAL_COORDINATE \uis new\n COORDINATE; -- two different types \utype\n MIDWEEK \uis new\n DAY \urange\n TUE .. THU; -- see 3.5.1 \utype\n COUNTER \uis new\n POSITIVE; -- same range as POSITIVE \utype\n SPECIAL_KEY \uis new\n KEY_MANAGER.KEY; -- see 7.4.2 -- the derived subprograms have the following specifications: -- \uprocedure\n GET_KEY(K : \uout\n SPECIAL_KEY); -- \ufunction\n "<"(X,Y : SPECIAL_KEY) \ureturn\n BOOLEAN; \uNotes:\n The rules of derivation of basic operations and enumeration literals imply that the notation for any \vliteral\v406. or \vaggregate\v407. of the derived type is the same as for the parent type; such literals and aggregates are said to be overloaded. Similarly, it follows that the notation for denoting a \vcomponent\v305., a \vdiscriminant\v305., an \ventry\v905., a \vslice\v403., or an \vattribute\v405. is the same for the derived type as for the parent type. Hiding of a derived subprogram is allowed even within the same \vdeclarative\v801. \vregion\v801. (see 8.3). A derived subprogram hides a predefined operator that has the same parameter and result type profile (see 6.6). A \vgeneric subprogram declaration\v1201. is not derivable since it declares a \vgeneric unit\v1200. rather than a subprogram. On the other hand, an instantiation of a \vgeneric subprogram\v1201. is a (nongeneric) subprogram, which is derivable if it satisfies the requirements for derivability of subprograms. If the parent type is a \vboolean type\v313., the predefined relational operators of the derived type deliver a result of the predefined type BOOLEAN (see 4.5.2). If a representation clause is given for the parent type but appears after the derived type declaration, then no corresponding representation clause applies to the derived type; hence an explicit representation clause for such a derived type is allowed. For a derived subprogram, if a parameter belongs to the derived type, the subtype of this parameter need not have any value in common with the derived subtype. 3.5 \uScalar Types\n Scalar types comprise \venumeration types\v311., integer types, and \vreal types\v316.. Enumeration types and \vinteger types\v314. are called discrete types; each value of a discrete type has a position number which is an integer value. Integer types and real types are called numeric types. All scalar types are ordered, that is, all \vrelational operators\v411. are predefined for their values. range_constraint ::= \urange\n range range ::= range_attribute | simple_expression .. simple_expression A range specifies a subset of values of a scalar type. The range L .. R specifies the values from L to R inclusive if the relation L <= R is true. The values L and R are called the lower bound and upper bound of the range, respectively. A value V is said to satisfy a range \vconstraint\v305. if it belongs to the range; the value V is said to belong to the range if the relations L <= V and V <= R are both TRUE. A null range is a range for which the relation R < L is TRUE; no value belongs to a null range. The operators <= and < in the above definitions are the predefined operators of the scalar type. If a range constraint is used in a \vsubtype indication\v307., either directly or as part of a \vfloating\v317. or \vfixed point constraint\v319., the type of the simple expressions (likewise, of the bounds of a range \vattribute\v405.) must be the same as the base type of the \vtype mark\v307. of the subtype indication. A range constraint is compatible with a subtype if each bound of the range belongs to the subtype, or if the range constraint defines a null range; otherwise the range constraint is not compatible with the subtype. The elaboration of a range constraint consists of the \vevaluation\v411. of the range. The evaluation of a range defines its lower bound and its upper bound. If \vsimple expressions\v410. are given to specify the bounds, the evaluation of the range evaluates these simple expressions in some order that is not defined by the language. Attributes For any scalar type T or for any subtype T of a scalar type, the following attributes are defined: T'FIRST Yields the lower bound of T. The value of this attribute has the same type as T. T'LAST Yields the upper bound of T. The value of this attribute has the same type as T. Note: Indexing and iteration rules use values of discrete types. More details: 3.5.1 \vEnumeration Types\v311. 3.5.2 \vCharacter Types\v312. 3.5.3 \vBoolean Types\v313. 3.5.4 \vInteger Types\v314. 3.5.5 \vOperations of Discrete Types\v315. 3.5.6 \vReal Types\v316. 3.5.7 \vFloating Point Types\v317. 3.5.8 \vOperations of Floating Point Types\v318. 3.5.9 \vFixed Point Types\v319. 3.5.10 \vOperations of fixed point types\v320. 3.5.1 Enumeration Types An enumeration \vtype definition\v306. defines an enumeration \vtype\v305.. enumeration_type_definition ::= (enumeration_literal_specification {, enumeration_literal_specification}) enumeration_literal_specification ::= enumeration_literal enumeration_literal ::= identifier | character_literal The identifiers and \vcharacter literals\v207. listed by an enumeration type definition must be distinct. Each enumeration literal specification is the \vdeclaration\v301. of the corresponding enumeration literal: this declaration is equivalent to the declaration of a parameterless \vfunction\v609., the \vdesignator\v601. being the enumeration literal, and the result type being the enumeration type. The \velaboration\v333. of an enumeration type definition creates an enumeration type; this elaboration includes that of every enumeration literal specification. Each enumeration literal yields a different enumeration value. The predefined order relations between enumeration values follow the order of corresponding \vposition numbers\v310.. The position number of the value of the first listed enumeration literal is zero; the position number for each other enumeration literal is one more than for its predecessor in the list. If the same identifier or character literal is specified in more than one enumeration type definition, the corresponding literals are said to be \voverloaded\v610.. At any place where an overloaded enumeration literal occurs in the text of a program, the type of the enumeration literal must be determinable from the context (see 8.7). \uExamples:\n \utype\n DAY \uis\n (MON, TUE, WED, THU, FRI, SAT, SUN); \utype\n SUIT \uis\n (CLUBS, DIAMONDS, HEARTS, SPADES); \utype\n GENDER \uis\n (M, F); \utype\n LEVEL \uis\n (LOW, MEDIUM, URGENT); \utype\n COLOR \uis\n (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK); \utype\n LIGHT \uis\n (RED, AMBER, GREEN); -- RED and GREEN are overloaded \utype\n HEXA \uis\n ('A', 'B', 'C', 'D', 'E', 'F'); \utype\n MIXED \uis\n ('A', 'B', '*', B, NONE, '?', '%'); \subtype\n WEEKDAY \uis\n DAY \urange\n MON .. FRI; \subtype\n MAJOR \uis\n SUIT \urange\n HEARTS .. SPADES; \subtype\n RAINBOW \uis\n COLOR \urange\n RED .. BLUE; -- the color RED, not the light Note: If an enumeration literal occurs in a context that does not otherwise suffice to determine the type of the literal, then qualification by the \vname\v401. of the enumeration type is one way to resolve the ambiguity (see 8.7). 3.5.2 \uCharacter Types\n An \venumeration type\v311. is said to be a character \vtype\v305. if at least one of its enumeration \vliterals\v406. is a \vcharacter literal\v207.. The predefined type CHARACTER is a character type whose values are the 128 characters of the ASCII character set. Each of the 95 \vgraphic characters\v201. of this character set is denoted by the corresponding character literal. Example: \utype\n ROMAN_DIGIT \uis\n ('I', 'V', 'X', 'L', 'C', 'D', 'M'); \uNotes:\n The \vpredefined package ASCII\v201. includes the \vdeclaration\v301. of constants denoting control characters and of \vconstants\v303. denoting graphic characters that are not in the basic character set. A conventional character set such as EBCDIC can be declared as a character type; the internal codes of the characters can be specified by an enumeration representation clause as explained in section 13.3. 3.5.3 \uBoolean Types\n There is a predefined enumeration type named BOOLEAN. It contains the two literals FALSE and TRUE ordered with the relation FALSE < TRUE. A boolean type is either the type BOOLEAN or a type that is \vderived\v309., directly or indirectly, from a boolean \vtype\v305.. 3.5.4 \uInteger Types\n An integer \vtype definition\v306. defines an integer type whose set of values includes at least those of the specified range. integer_type_definition ::= \vrange_constraint\v310. If a range constraint is used as an integer type definition, each \vbound of\v310. \vthe range\v310. must be defined by a \vstatic expression\v422. of some integer type, but the two bounds need not have the same integer type. (Negative bounds are allowed.) A type declaration of the form: \utype\n T \uis range\n L .. R; is, by definition, equivalent to the following declarations: \utype\n integer_type \uis new\n predefined_integer_type; \usubtype\n T \uis\n integer_type \urange\n integer_type(L) .. integer_type(R); where integer_type is an \vanonymous type\v306., and where the predefined integer type is implicitly selected by the implementation, so as to contain the values L to R inclusive. The integer \vtype declaration\v306. is illegal if none of the predefined integer types satisfies this requirement, excepting \vuniversal_integer\v401.. The elaboration of the declaration of an integer type consists of the elaboration of the equivalent type and \vsubtype\v307. \vdeclarations\v307.. The predefined integer types include the type INTEGER. An implementation may also have predefined types such as SHORT_INTEGER and LONG_INTEGER, which have (substantially) shorter and longer ranges, respectively, than INTEGER. The range of each of these types must be symmetric about zero, excepting an extra negative value which may exist in some implementations. The base type of each of these types is the type itself. \vInteger literals\v204. are the \vliterals\v406. of an anonymous predefined integer type that is called universal_integer in this reference manual. Other integer types have no literals. However, for each integer type there exists an implicit \vconversion\v419. that converts a universal_integer value into the corresponding value (if any) of the integer type. The circumstances under which these implicit conversions are invoked are described in section 4.6. The position number of an integer value is the corresponding value of the type universal_integer. The same arithmetic operators are predefined for all integer types (see 4.5). The exception NUMERIC_ERROR is raised by the execution of an operation (in particular an implicit conversion) that cannot deliver the correct result (that is, if the value corresponding to the mathematical result is not a value of the integer type). However, an implementation is not required to raise the \vexception NUMERIC_ERROR\v1101. if the operation is part of a larger expression whose result can be computed correctly, as described in section 11.6. \uExamples:\n \utype\n PAGE_NUM \uis range\n 1 .. 2_ \utype\n LINE_SIZE \uis range\n 1 .. MAX_LINE_SIZE; \usubtype\n SMALL_INT \uis\n INTEGER \urange\n -10 .. 10; \usubtype\n COLUMN_PTR \uis\n LINE_SIZE \urange\n 1 .. 10; \usubtype\n BUFFER_SIZE \uis\n INTEGER \urange\n 0 .. MAX; \uNotes:\n The name declared by an integer type declaration is a subtype name. On the other hand, the \vpredefined operators\v411. of an integer type deliver results whose range is defined by the \vparent predefined type\v309.; such a result need not \vbelong to the declared subtype\v305., in which case an attempt to assign the result to a variable of the integer subtype raises the exception \vCONSTRAINT_ERROR\v1101.. The smallest (most negative) value supported by the predefined integer types of an implementation is the named number SYSTEM.MIN_INT and the largest (most positive) value is SYSTEM.MAX_INT (see 13.7). 3.5.5 \uOperations of Discrete Types\n The basic \voperations\v305. of a discrete type include the operations involved in assignment, the \vmembership tests\v411., and qualification; for a \vboolean type\v313. they include the short-circuit control forms; for an \vinteger type\v314. they include the explicit \vconversion\v419. of values of other \vnumeric types\v310. to the integer type, and the implicit conversion of values of the type \vuniversal_integer to the type\v314.. Finally, for every \vdiscrete type\v310. or subtype T, the basic operations include the attributes listed below. In this presentation, T is referred to as being a subtype (the subtype T) for any property that depends on \vconstraints\v305. imposed by T; other properties are stated in terms of the \vbase\v305. \vtype\v305. of T. The first group of attributes yield characteristics of the subtype T. This group includes the attribute BASE (see 3.3.2), the attributes FIRST and LAST (see 3.5), the representation attribute SIZE (see 13.7.2), and the attribute WIDTH defined as follows: T'WIDTH Yields the maximum image length over all values of the subtype T (the image is the sequence of characters returned by the attribute IMAGE, see below). Yields zero for a null range. The value of this attribute is of the type universal_integer. All attributes of the second group are \vfunctions\v609. with a single parameter. The corresponding actual parameter is indicated below by X. T'POS This attribute is a function. The parameter X must be a value of the base type of T. The result type is the type universal_integer. The result is the \vposition number\v310. of the value of the parameter. T'VAL This attribute is a special function with a single parameter which can be of any integer type. The result type is the base type of T. The result is the value whose position number is the universal_integer value corresponding to X. The exception \vCONSTRAINT_ERROR\v1101. is raised if the universal_integer value corresponding to X is not in the range T'POS(T'BASE'FIRST) .. T'POS(T'BASE'LAST). T'SUCC This attribute is a function. The parameter X must be a value of the base type of T. The result type is the base type of T. The result is the value whose position number is one greater than that of X. The exception CONSTRAINT_ERROR is raised if X equals T'BASE'LAST. T'PRED This attribute is a function. The parameter X must be a value of the base type of T. The result type is the base type of T. The result is the value whose position number is one less than that of X. The \vexception CONSTRAINT_ERROR\v1101. is raised if X equals T'BASE'FIRST. T'IMAGE This attribute is a function. The parameter X must be a value of the base type of T. The result type is the predefined type STRING. The result is the image of the value of X, that is, a sequence of characters representing the value in display form. The image of an integer value is the corresponding decimal literal; without underlines, leading zeros, exponent, or trailing spaces; but with a single leading character that is either a minus sign or a space. The lower bound of the image is one. The image of an enumeration value is either the corresponding \videntifier\v203. in upper case or the corresponding \vcharacter literal\v207. (including the two apostrophes); neither leading nor trailing spaces are included. The image of a character C, other than a \vgraphic character\v201., is implementation-defined; the only requirement is that the image must be such that C equals CHARACTER'VALUE(CHARACTER'IMAGE(C)). T'VALUE This attribute is a function. The parameter X must be a value of the predefined type STRING. The result type is the base type of T. Any leading and any trailing spaces of the sequence of characters that corresponds to the parameter are ignored. For an enumeration type, if the sequence of characters has the syntax of an \venumeration literal\v311. and if this literal exists for the base type of T, the result is the corresponding enumeration value. For an integer type, if the sequence of characters has the syntax of an integer literal, with an optional single leading character that is a plus or minus sign, and if there is a corresponding value in the base type of T, the result is this value. In any other case, the exception CONSTRAINT_ERROR is raised. In addition, the attributes A'SIZE and A'ADDRESS are defined for an \vobject\v302. A of a discrete type (see 13.7.2). Besides the \vbasic operations\v308., the operations of a discrete type include the predefined relational operators. For enumeration types, operations include enumeration literals. For boolean types, operations include the predefined unary logical negation \voperator not\v411., and the predefined \vlogical operators\v411.. For integer types, operations include the predefined arithmetic operators: these are the \vbinary and unary adding operators\v411. - and +, all \vmultiplying\v411. \voperators\v411., the unary \voperator abs\v411., and the \vexponentiating operator\v411.. The operations of a subtype are the corresponding operations of its base type except for the following: \vassignment\v502., membership tests, qualification, explicit type \vconversions\v419., and the \vattributes\v405. of the first group; the effect of each of these operations depends on the subtype (assignments, membership tests, qualifications, and conversions involve a subtype check; attributes of the first group yield a characteristic of the subtype). \uNotes:\n For a subtype of a discrete type, the results delivered by the attributes SUCC, PRED, VAL, and VALUE need not belong to the subtype; similarly, the actual parameters of the attributes POS, SUCC, PRED, and IMAGE need not belong to the subtype. The following relations are satisfied (in the absence of an exception) by these attributes: T'POS(T'SUCC(X)) = T'POS(X) + 1 T'POS(T'PRED(X)) = T'POS(X) - 1 T'VAL(T'POS(X)) = X T'POS(T'VAL(N)) = N \uExamples:\n -- For the types and subtypes declared in section 3.5.1 we have: -- COLOR'FIRST = WHITE, COLOR'LAST = BLACK -- RAINBOW'FIRST = RED, RAINBOW'LAST = BLUE -- COLOR'SUCC(BLUE) = RAINBOW'SUCC(BLUE) = BROWN -- COLOR'POS(BLUE) = RAINBOW'POS(BLUE) = 4 -- COLOR'VAL(0) = RAINBOW'VAL(0) = WHITE 3.5.6 \uReal Types\n Real \vtypes\v305. provide approximations to the real numbers, with relative bounds on errors for floating point types, and with absolute bounds for fixed point types. real_type_definition ::= \vfloating_point_constraint\v317. | fixed_point_constraint A set of numbers called model numbers is associated with each real type. Error bounds on the \vpredefined operations\v308. are given in terms of the model numbers. An implementation of the type must include at least these model numbers and represent them exactly. An implementation-dependent set of numbers, called the safe numbers, is also associated with each real type. The set of safe numbers of a real type must include at least the set of model numbers of the type. The range of safe numbers is allowed to be larger than the range of model numbers, but error bounds on the predefined operations for safe numbers are given by the same rules as for model numbers. Safe numbers therefore provide guaranteed error bounds for operations on an implementation-dependent range of numbers; in contrast, the range of model numbers depends only on the real \vtype definition\v306. and is therefore independent of the implementation. Real \vliterals\v204. are the \vliterals\v406. of an anonymous predefined real type that is called universal_real in this reference manual. Other real types have no literals. However, for each real type, there exists an implicit \vconversion\v419. that converts a universal_real value into a value of the real type. The conditions under which these implicit conversions are invoked are described in section 4.6. If the universal_real value is a safe number, the implicit conversion delivers the corresponding value; if it belongs to the range of safe numbers but is not a safe number, then the converted value can be any value within the range defined by the safe numbers next above and below the universal_real value. The execution of an operation that yields a value of a real type may raise the \vexception NUMERIC_ERROR\v1101., as explained in section 4.5.7, if it cannot deliver a correct result (that is, if the value corresponding to one of the possible mathematical results does not belong to the range of safe numbers); in particular, this exception can be raised by an implicit conversion. However, an implementation is not required to raise the exception NUMERIC_ERROR if the operation is part of a larger expression whose result can be computed correctly (see 11.6). The \velaboration\v333. of a real type definition includes the elaboration of the floating or \vfixed point constraint\v319. and creates a real type. Note: An algorithm written to rely only upon the minimum numerical properties guaranteed by the type definition for model numbers will be portable without further precautions. 3.5.7 \uFloating Point Types\n For floating point \vtypes\v305., the \verror bound\v316. is specified as a relative precision by giving the required minimum number of significant decimal digits. floating_point_constraint ::= floating_accuracy_definition [range_constraint] floating_accuracy_definition ::= \udigits\n static_simple_expression The minimum number of significant decimal digits is specified by the value of the static \vsimple expression\v410. of the floating accuracy definition. This value must belong to some \vinteger type\v314. and must be positive (nonzero); it is denoted by D in the remainder of this section. If the floating point constraint is used as a real type definition and includes a range constraint, then each \vbound of the range\v310. must be defined by a \vstatic\v422. \vexpression\v422. of some real type, but the two bounds need not have the same \vreal type\v316.. For a given radix, the following canonical form is defined for any floating point \vmodel number\v316. other than zero: sign * mantissa * (radix ** \vexponent\v205.) In this form: sign is either +1 or -1; mantissa is expressed in a number base given by radix; and exponent is an integer number (possibly negative) such that the integer part of mantissa is zero and the first digit of its fractional part is not a zero. The specified number D is the minimum number of decimal digits required after the point in the decimal mantissa (that is, if radix is ten). The value of D in turn determines a corresponding number B that is the minimum number of binary digits required after the point in the binary mantissa (that is, if radix is two). The number B associated with D is the smallest value such that the relative precision of the binary form is no less than that specified for the decimal form. (The number B is the integer next above (D*log(10)/log(2)) + 1.) The model numbers defined by a floating accuracy definition comprise zero and all numbers whose binary canonical form has exactly B digits after the point in the mantissa and an exponent in the range -4*B .. +4*B. The guaranteed minimum accuracy of \voperations\v305. of a floating point type is defined in terms of the model numbers of the floating point constraint that forms the corresponding \vreal type definition\v316. (see 4.5.7). The predefined floating point types include the type FLOAT. An implementation may also have predefined types such as SHORT_FLOAT and LONG_FLOAT, which have (substantially) less and more accuracy, respectively, than FLOAT. The base type of each predefined floating point type is the type itself. The model numbers of each predefined floating point type are defined in terms of the number D of decimal digits returned by the attribute DIGITS (see 3.5.8). For each predefined floating point type (consequently also for each \vtype\v309. \vderived\v309. therefrom), a set of \vsafe numbers\v316. is defined as follows. The safe numbers have the same number B of mantissa \vdigits\v201. as the model numbers of the type and have an exponent in the range -E .. +E where E is implementation-defined and at least equal to the 4*B of model numbers. (Consequently, the safe numbers include the model numbers.) The rules defining the accuracy of operations with model and safe numbers are given in section 4.5.7. The safe numbers of a subtype are those of its base type. A floating point \vtype declaration\v306. of one of the two forms (that is, with or without the optional range constraint indicated by the square brackets): \utype\n T \uis digits\n D [\urange\n L .. R]; is, by definition, equivalent to the following declarations: \utype\n floating_point_type \uis new\n predefined_floating_point_type; \usubtype\n T \uis\n floating_point_type \udigits\n D [\urange\n floating_point_type(L) .. floating_point_type(R)]; where floating_point_type is an \vanonymous type\v306., and where the predefined floating point type is implicitly selected by the implementation so that its model numbers include the model numbers defined by D; furthermore, if a range L .. R is supplied, then both L and R must belong to the range of safe numbers. The floating point declaration is illegal if none of the predefined floating point types satisfies these requirements, excepting universal_real. The maximum number of digits that can be specified in a floating accuracy definition is given by the system-dependent named number SYSTEM.MAX_DIGITS (see 13.7.1). The \velaboration\v301. of a floating point type declaration consists of the elaboration of the equivalent type and \vsubtype declarations\v307.. If a floating point constraint follows a \vtype mark\v307. in a \vsubtype indication\v307., the type mark must denote a floating point type or \vsubtype\v305.. The floating point constraint is \vcompatible\v307. with the type mark only if the number D specified in the floating accuracy definition is not greater than the corresponding number D for the type or subtype denoted by the type mark. Furthermore, if the floating point constraint includes a range constraint, the floating point constraint is compatible with the type mark only if the range constraint is, itself, compatible with the type mark. The elaboration of such a subtype indication includes the elaboration of the range constraint, if there is one; it creates a floating point subtype whose model numbers are defined by the corresponding floating accuracy definition. A value of a floating point type belongs to a floating point subtype if and only if it \vbelongs to the range defined by the subtype\v305.. The same \varithmetic operators\v315. are predefined for all floating point types (see 4.5). \uNotes:\n A range constraint is allowed in a floating point subtype indication, either directly after the type mark, or as part of a floating point constraint. In either case the bounds of the range must belong to the base type of the type mark (see 3.5). The imposition of a floating point constraint on a type mark in a subtype indication cannot reduce the allowed range of values unless it includes a range constraint (the range of model numbers that correspond to the specified number of digits can be smaller than the range of numbers of the type mark). A value that belongs to a floating point subtype need not be a model number of the subtype. \uExamples:\n \utype\n COEFFICIENT \uis digits\n 10 range -1.0 .. 1.0; \utype\n REAL \uis digits\n 8; \utype\n MASS \uis digits\n 7 \urange\n 0.0 .. 1.0E35; \usubtype\n SHORT_COEFF \uis\n COEFFICIENT \udigits\n 5; -- a subtype with less accuracy \usubtype\n PROBABILITY \uis\n REAL \urange\n 0.0 .. 1.0; -- a subtype with a smaller range Notes on the examples: The implemented accuracy for COEFFICIENT is that of a predefined type having at least 10 digits of precision. Consequently the specification of 5 digits of precision for the subtype SHORT_COEFF is allowed. The largest model number for the type MASS is approximately 1.27E30 and hence less than the specified upper bound (1.0E35). Consequently the declaration of this type is legal only if this upper bound is in the range of the safe numbers of a predefined floating point type having at least 7 digits of precision. 3.5.8 \uOperations of Floating Point Types\n The \vbasic operations\v308. of a \vfloating point type\v317. include the \voperations\v305. involved in \vassignment\v502., \vmembership tests\v411., qualification, the explicit \vconversion\v419. of values of other \vnumeric types\v310. to the floating point \vtype\v305., and the implicit conversion of values of the type \vuniversal_real\v316. to the type. In addition, for every floating point type or \vsubtype\v305. T, the basic operations include the \vattributes\v405. listed below. In this presentation, T is referred to as being a subtype (the subtype T) for any property that depends on \vconstraints\v305. imposed by T; other properties are stated in terms of the \vbase type\v305. of T. The first group of attributes yield characteristics of the subtype T. The attributes of this group are the attribute BASE (see 3.3.2), the attributes FIRST and LAST (see 3.5), the representation attribute SIZE (see 13.7.2), and the following attributes: T'DIGITS Yields the number of decimal \vdigits\v201. in the decimal mantissa of \vmodel numbers\v316. of the subtype T. (This attribute yields the number D of section 3.5.7.) The value of this attribute is of the \vtype universal_integer\v314.. T'MANTISSA Yields the number of binary digits in the binary mantissa of model numbers of the subtype T. (This attribute yields the number B of section 3.5.7.) The value of this attribute is of the type universal_integer. T'EPSILON Yields the absolute value of the difference between the model number 1.0 and the next model number above, for the subtype T. The value of this attribute is of the type universal_real. T'EMAX Yields the largest exponent value in the binary canonical form of model numbers of the subtype T. (This attribute yields the product 4*B of section 3.5.7.) The value of this attribute is of the type universal_integer. T'SMALL Yields the smallest positive (nonzero) model number of the subtype T. The value of this attribute is of the type universal_real. T'LARGE Yields the largest positive model number of the subtype T. The value of this attribute is of the type universal_real. The attributes of the second group include the following attributes which yield characteristics of the safe numbers: T'SAFE_EMAX Yields the largest exponent value in the binary canonical form of safe numbers of the base type of T. (This attribute yields the number E of section 3.5.7.) The value of this attribute is of the type universal_integer. T'SAFE_SMALL Yields the smallest positive (nonzero) safe number of the base type of T. The value of this attribute is of the type universal_real. T'SAFE_LARGE Yields the largest positive safe number of the base type of T. The value of this attribute is of the type universal_real. In addition, the attributes A'SIZE and A'ADDRESS are defined for an \vobject\v302. A of a floating point type (see 13.7.2). Finally, for each floating point type there are machine-dependent attributes that are not related to model numbers and safe numbers. They correspond to the attribute designators MACHINE_RADIX, MACHINE_MANTISSA, MACHINE_EMAX, MACHINE_EMIN, MACHINE_ROUNDS, and MACHINE_OVERFLOWS (see 13.7.3). Besides the basic operations, the operations of a floating point type include the \vrelational operators\v411., and the following predefined \varithmetic\v315. \voperators\v315.: the binary and \vunary adding operators\v411. - and +, the \vmultiplying\v411. operators * and /, the unary \voperator abs\v411., and the \vexponentiating\v411. \voperator\v411.. The operations of a subtype are the corresponding operations of the type except for the following: assignment, membership tests, qualification, explicit conversion, and the attributes of the first group; the effects of these operations are redefined in terms of the subtype. \uNotes:\n The attributes EMAX, SMALL, LARGE, and EPSILON are provided for convenience. They are all related to MANTISSA by the following formulas: T'EMAX = 4*T'MANTISSA T'EPSILON = 2.0**(1 - T'MANTISSA) T'SMALL = 2.0**(-T'EMAX - 1) T'LARGE = 2.0**T'EMAX * (1.0 - 2.0**(-T'MANTISSA)) The attribute MANTISSA, giving the number of binary digits in the mantissa, is itself related to DIGITS. The following relations hold between the characteristics of the model numbers and those of the \vsafe numbers\v311.: T'BASE'EMAX <= T'SAFE_EMAX T'BASE'SMALL >= T'SAFE_SMALL T'BASE'LARGE <= T'SAFE_LARGE The attributes T'FIRST and T'LAST need not yield model or safe numbers. If a certain number of digits is specified in the declaration of a type or subtype T, the attribute T'DIGITS yields this number. 3.5.9 \uFixed Point Types\n For fixed point types, the \verror bound\v316. is specified as an absolute value, called the delta of the fixed point \vtype\v305.. fixed_point_constraint ::= fixed_accuracy_definition [range_constraint] fixed_accuracy_definition ::= \udelta\n static_simple_expression The \udelta\n is specified by the value of the static \vsimple expression\v410. of the fixed accuracy definition. This value must belong to some real type and must be positive (nonzero). If the fixed point constraint is used as a \vreal type\v316. definition, then it must include a range constraint; each bound of the specified range must be defined by a \vstatic expression\v422. of some real type but the two bounds need not have the same real type. If the fixed point constraint is used in a \vsubtype indication\v307., the range constraint is optional. A canonical form is defined for any fixed point \vmodel number\v316. other than zero. In this form: sign is either +1 or -1; mantissa is a positive (nonzero) integer; and any model number is a multiple of a certain positive real number called small, as follows: sign * mantissa * small For the model numbers defined by a fixed point constraint, the number small is chosen as the largest power of two that is not greater than the delta of the fixed accuracy definition. Alternatively, it is possible to specify the value of small by a \vlength clause\v1302. (see 13.2), in which case model numbers are multiples of the specified value. The guaranteed minimum accuracy of \voperations\v305. of a fixed point type is defined in terms of the model numbers of the fixed point constraint that forms the corresponding real type definition (see 4.5.7). For a fixed point constraint that includes a range constraint, the model numbers comprise zero and all multiples of small whose mantissa can be expressed using exactly B binary digits, where the value of B is chosen as the smallest integer number for which each \vbound of the specified range\v310. is either a model number or lies at most small distant from a model number. For a fixed point constraint that does not include a range constraint (this is only allowed after a \vtype mark\v307., in a subtype indication), the model numbers are defined by the delta of the fixed accuracy definition and by the range of the subtype denoted by the type mark. An implementation must have at least one anonymous predefined fixed point type. The \vbase type\v305. of each such fixed point type is the type itself. The model numbers of each predefined fixed point type comprise zero and all numbers for which mantissa (in the canonical form) has the number of binary digits returned by the attribute MANTISSA, and for which the number small has the value returned by the attribute SMALL. A fixed point \vtype declaration\v306. of the form: \utype\n T \uis delta\n D \urange\n L .. R; is, by definition, equivalent to the following declarations: \utype\n fixed_point_type \uis new\n predefined_fixed_point_type; \usubtype\n T \uis\n fixed_point_type \urange\n fixed_point_type(L) .. fixed_point_type(R); In these declarations, fixed_point_type is an \vanonymous type\v306., and the predefined fixed point type is implicitly selected by the implementation so that its model numbers include the model numbers defined by the fixed point constraint (that is, by D, L, and R, and possibly by a length clause specifying small). The fixed point declaration is illegal if no predefined type satisfies these requirements. The \vsafe numbers\v316. of a fixed point type are the model numbers of its base type. The \velaboration\v333. of a fixed point type declaration consists of the elaboration of the equivalent type and \vsubtype declarations\v307.. If the fixed point constraint follows a type mark in a subtype indication, the type mark must denote a fixed point type or subtype. The fixed point constraint is \vcompatible\v307. with the type mark only if the delta specified by the fixed accuracy definition is not smaller than the delta for the type or subtype denoted by the type mark. Furthermore, if the fixed point constraint includes a range constraint, the fixed point constraint is compatible with the type mark only if the range constraint is, itself, compatible with the type mark. The elaboration of such a subtype indication includes the elaboration of the range constraint, if there is one; it creates a fixed point subtype whose model numbers are defined by the corresponding fixed point constraint and also by the length clause specifying small, if there is one. A value of a fixed point type \vbelongs to a fixed point subtype\v305. if and only if it belongs to the range defined by the subtype. The same \varithmetic operators\v310. are predefined for all fixed point types (see 4.5). Multiplication and division of fixed point values deliver results of an anonymous predefined fixed point type that is called universal_fixed in this reference manual; the accuracy of this type is arbitrarily fine. The values of this type must be converted explicitly to some \vnumeric type\v310.. \uNotes:\n If S is a subtype of a fixed point type or subtype T, then the set of model numbers of S is a subset of those of T. If a length clause has been given for T, then both S and T have the same value for small. Otherwise, since small is a power of two, the small of S is equal to the small of T multiplied by a nonnegative power of two. A range constraint is allowed in a fixed point subtype indication, either directly after the type mark, or as part of a fixed point constraint. In either case the bounds of the range must belong to the base type of the type mark (see 3.5). \uExamples:\n \utype\n VOLT \uis delta\n 0.125 \urange\n 0.0 .. 255.0; \usubtype\n ROUGH_VOLTAGE \uis\n VOLT \udelta\n 1.0; -- same range as VOLT -- A pure fraction which requires all the available space in a word -- on a two's complement machine can be declared as the type FRACTION: DEL : \uconstant\n := 1.0/2**(WORD_LENGTH - 1); \utype\n FRACTION \uis delta\n DEL \urange\n -1.0 .. 1.0 - DEL; 3.5.10 \uOperations of Fixed Point Types\n The \vbasic operations\v308. of a \vfixed point type\v319. include the \voperations\v305. involved in \vassignment\v502., \vmembership tests\v411., qualification, the explicit \vconversion\v419. of values of other \vnumeric types\v310. to the fixed point type, and the implicit conversion of values of the type \vuniversal_real\v316. to the type. In addition, for every fixed point type or \vsubtype\v305. T the basic operations include the attributes listed below. In this presentation T is referred to as being a subtype (the subtype T) for any property that depends on constraints imposed by T; other properties are stated in terms of the base type of T. The first group of attributes yield characteristics of the subtype T. The attributes of this group are the attributes BASE (see 3.3.2), the attributes FIRST and LAST (see 3.5), the representation attribute SIZE (see 13.7.2) and the following attributes: T'DELTA Yields the value of the \vdelta\v319. specified in the fixed accuracy definition for the subtype T. The value of this attribute is of the type universal_real. T'MANTISSA Yields the number of binary digits in the mantissa of model numbers of the subtype T. (This attribute yields the number B of section 3.5.9.) The value of this attribute is of the type \vuniversal_integer\v314.. T'SMALL Yields the smallest positive (nonzero) \vmodel number\v316. of the subtype T. The value of this attribute is of the type universal_real. T'LARGE Yields the largest positive model number of the subtype T. The value of this attribute is of the type universal_real. T'FORE Yields the minimum number of characters needed for the integer part of the decimal representation of any value of the subtype T, assuming that the representation does not include an exponent, but includes a one-character prefix that is either a minus sign or a space. (This minimum number does not include superfluous zeros or underlines, and is at least two.) The value of this attribute is of the type universal_integer. T'AFT Yields the number of decimal digits needed after the point to accommodate the precision of the subtype T, unless the delta of the subtype T is greater than 0.1, in which case the attribute yields the value one. (T'AFT is the smallest positive integer N for which (10**N)*T'DELTA is greater than or equal to one.) The value of this attribute is of the type universal_integer. The attributes of the second group include the following attributes which yield characteristics of the \vsafe numbers\v316.: T'SAFE_SMALL Yields the smallest positive (nonzero) safe number of the base type of T. The value of this attribute is of the type universal_real. T'SAFE_LARGE Yields the largest positive safe number of the \vbase type\v305. of T. The value of this attribute is of the type universal_real. In addition, the attributes A'SIZE and A'ADDRESS are defined for an \vobject\v302. A of a fixed point type (see 13.7.2). Finally, for each fixed point type or subtype T, there are the machine-dependent attributes T'MACHINE_ROUNDS and T'MACHINE_OVERFLOWS (see 13.7.3). Besides the basic operations, the operations of a fixed point type include the \vrelational operators\v411., and the following predefined \varithmetic\v315. \voperators\v315.: the binary and unary \vadding operators\v411. - and +, the \vmultiplying\v411. operators * and /, and the operator \uabs\n. The operations of a subtype are the corresponding operations of the type except for the following: assignment, membership tests, qualification, explicit conversion, and the attributes of the first group; the effects of these operations are redefined in terms of the subtype. \uNotes:\n The value of the attribute T'FORE depends only on the range of the subtype T. The value of the attribute T'AFT depends only on the value of T'DELTA. The following relations exist between attributes of a fixed point type: T'LARGE = (2**T'MANTISSA - 1) * T'SMALL T'SAFE_LARGE = T'BASE'LARGE T'SAFE_SMALL = T'BASE'SMALL 3.6 \uArray Types\n An array object is a composite object consisting of \vcomponents\v305. that have the same subtype. The \vname\v401. for a component of an array uses one or more index values belonging to specified \vdiscrete types\v310.. The value of an array \vobject\v302. is a composite value consisting of the values of its components. array_type_definition ::= unconstrained_array_definition | constrained_array_definition unconstrained_array_definition ::= \uarray\n(index_subtype_definition {, index_subtype_definition}) \uof\n component_subtype_indication constrained_array_definition ::= \uarray\n index_constraint \uof\n component_subtype_indication index_subtype_definition ::= type_mark \urange\n <> index_constraint ::= (discrete_range {, discrete_range}) discrete_range ::= discrete_subtype_indication | \urange\n An array object is characterized by the number of indices (the dimensionality of the array), the type and position of each index, the lower and upper bounds for each index, and the type and possible \vconstraint\v305. of the components. The order of the indices is significant. A one-dimensional array has a distinct component for each possible index value. A multidimensional array has a distinct component for each possible sequence of index values that can be formed by selecting one value for each index position (in the given order). The possible values for a given index are all the values between the lower and upper bounds, inclusive; this \vrange\v305. of values is called the index range. An unconstrained array definition defines an array type. For each object that has the array type, the number of indices, the type and position of each index, and the subtype of the components are as in the type definition; the values of the lower and upper bounds for each index belong to the corresponding index subtype, except for null arrays as explained in section 3.6.1. The index subtype for a given index position is, by definition, the subtype denoted by the \vtype mark\v307. of the corresponding index subtype definition. The compound delimiter <> (called a box) of an index subtype definition stands for an undefined range (different objects of the type need not have the same bounds). The \velaboration\v301. of an unconstrained array definition creates an array type; this elaboration includes that of the component subtype indication. A constrained array definition defines both an array type and a subtype of this type: - The array type is an implicitly declared \vanonymous type\v306.; this type is defined by an (implicit) unconstrained array definition, in which the component subtype indication is that of the constrained array definition, and in which the type mark of each index subtype definition denotes the subtype defined by the corresponding discrete range. - The array subtype is the subtype obtained by imposition of the index constraint on the array type. If a constrained array definition is given for a \vtype declaration\v306., the simple name declared by this declaration denotes the array subtype. The elaboration of a constrained array definition creates the corresponding array type and array subtype. For this elaboration, the index constraint and the component subtype indication are elaborated. The evaluation of each discrete range of the index constraint and the elaboration of the component subtype indication are performed in some order that is not defined by the language. Examples of type declarations with unconstrained array definitions: \utype\n VECTOR \uis array\n(INTEGER \urange\n <>) \uof\n REAL; \utype\n MATRIX \uis array\n(INTEGER \urange\n <>, INTEGER \urange\n <>) \uof\n REAL; \utype\n BIT_VECTOR \uis array\n(INTEGER \urange\n <>) \uof\n BOOLEAN; \utype\n ROMAN \uis array\n(POSITIVE \urange\n <>) \uof\n ROMAN_DIGIT; Examples of type declarations with constrained array definitions: \utype\n TABLE \uis array\n(1 .. 10) \uof\n INTEGER; \utype\n SCHEDULE \uis array\n(DAY) \uof\n BOOLEAN; \utype\n LINE \uis array\n(1 .. MAX_LINE_SIZE) \uof\n CHARACTER; Examples of object declarations with constrained array definitions: GRID : \uarray\n(1 .. 80, 1 .. 100) \uof\n BOOLEAN; MIX : \uarray\n(COLOR \urange\n RED .. GREEN) \uof\n BOOLEAN; PAGE : \uarray\n(1 .. 50) \uof\n LINE; -- an array of arrays Note: For a one-dimensional array, the rule given means that a type declaration with a constrained array definition such as \utype\n T \uis array\n(POSITIVE \urange\n MIN .. MAX) \uof\n COMPONENT; is equivalent (in the absence of an incorrect order dependence) to the succession of declarations \usubtype\n index_subtype \uis\n POSITIVE \urange\n MIN .. MAX; \utype\n array_type \uis\n \uarray\n(index_subtype range <>) \uof\n COMPONENT; \usubtype\n T \uis\n array_type (index_subtype); where index_subtype and array_type are both anonymous. Consequently, T is the name of a subtype and all objects declared with this type mark are arrays that have the same bounds. Similar transformations apply to multidimensional arrays. A similar transformation applies to an object whose declaration includes a constrained array definition. A consequence of this is that no two such objects have the same type. More details: 3.6.1 \vIndex Constraints and Discrete Ranges\v322. 3.6.2 \vOperations of Array Types\v323. 3.6.3 \vThe Type String\v324. 3.6.1 \uIndex Constraints and Discrete Ranges\n An \vindex constraint\v322. determines the \vrange\v310. of possible values for every \vindex\v321. of an \varray type\v321., and thereby the corresponding \varray bounds\v321.. For a \vdiscrete range\v321. used in a constrained \varray definition\v321. and defined by a range, an implicit \vconversion\v419. to the predefined type INTEGER is assumed if each bound is either a numeric literal, a named number, or an attribute, and the type of both bounds (prior to the implicit conversion) is the type universal_integer. Otherwise, both bounds must be of the same discrete type, other than \vuniversal_integer\v314.; this type must be determinable independently of the context, but using the fact that the type must be discrete and that both bounds must have the same type. These rules apply also to a discrete range used in an \viteration rule\v506. (see 5.5) or in the declaration of a family of entries (see 9.5). If an index constraint follows a \vtype mark\v307. in a \vsubtype indication\v307., then the type or subtype denoted by the type mark must not already impose an index constraint. The type mark must denote either an \vunconstrained array\v321. type or an \vaccess type\v330. whose \vdesignated\v330. type is such an array type. In either case, the index constraint must provide a discrete range for each index of the array type and the type of each discrete range must be the same as that of the corresponding index. An index constraint is \vcompatible\v307. with the type denoted by the type mark if and only if the constraint defined by each discrete range is compatible with the corresponding \vindex subtype\v321.. If any of the discrete ranges defines a \vnull range\v310., any array thus constrained is a null array, having no components. An array value satisfies an index constraint if at each index position the array value and the index constraint have the same index bounds. (Note, however, that assignment and certain other operations on arrays involve an implicit \vsubtype conversion\v419..) The bounds of each array \vobject\v302. are determined as follows: - For a \vvariable\v303. declared by an \vobject declaration\v303., the subtype indication of the corresponding object declaration must define a \vconstrained array subtype\v321. (and, thereby, the bounds). The same requirement exists for the subtype indication of a \vcomponent\v325. \vdeclaration\v325., if the type of the \vrecord component\v325. is an array type; and for the component subtype indication of an array type definition, if the type of the array components is itself an array type. - For a \vconstant\v303. declared by an object declaration, the bounds of the constant are defined by the \vinitial value\v303. if the subtype of the constant is unconstrained; they are otherwise defined by this subtype (in the latter case, the initial value is the result of an implicit subtype conversion). The same rule applies to a \vgeneric formal\v1201. parameter of \vmode\v1202. in. - For an array object designated by an \vaccess value\v330., the bounds must be defined by the \vallocator\v421. that creates the array object. (The allocated object is constrained with the corresponding values of the bounds.) - For a \vformal parameter\v601. of a \vsubprogram\v600. or \ventry\v905., the bounds are obtained from the corresponding \vactual parameter\v607.. (The formal parameter is constrained with the corresponding values of the bounds.) - For a \vrenaming declaration\v805. and for a generic \vformal parameter\v601. of mode in out, the bounds are those of the renamed object or of the corresponding \vgeneric actual parameter\v1206.. For the elaboration of an index constraint, the discrete ranges are evaluated in some order that is not defined by the language. Examples of array declarations including an index constraint: BOARD : MATRIX(1 .. 8, 1 .. 8); -- see 3.6 RECTANGLE : MATRIX(1 .. 20, 1 .. 30); INVERSE : MATRIX(1 .. N, 1 .. N); -- N need not be static FILTER : BIT_VECTOR(0 .. 31); Example of array declaration with a constrained array subtype: MY_SCHEDULE : SCHEDULE; -- all arrays of type SCHEDULE have the same bounds Example of record type with a component that is an array: \utype\n VAR_LINE(LENGTH : INTEGER) \uis\n \urecord\n IMAGE : STRING(1 .. LENGTH); \uend record\n; NULL_LINE : VAR_LINE(0); -- NULL_LINE.IMAGE is a null array \uNotes:\n The elaboration of a subtype indication consisting of a type mark followed by an index constraint checks the compatibility of the index constraint with the type mark (see 3.3.2). All components of an array have the same subtype. In particular, for an array of components that are one-dimensional arrays, this means that all components have the same bounds and hence the same length. 3.6.2 \uOperations of Array Types\n The \vbasic operations\v308. of an array type include the operations involved in \vassignment\v502. and \vaggregates\v407. (unless the \varray type\v321. is limited), \vmembership\v411. \vtests\v411., \vindexed components\v402., qualification, and explicit \vconversion\v419.; for one-dimensional arrays the basic operations also include the operations involved in \vslices\v403., and also \vstring literals\v208. if the component type is a \vcharacter type\v312.. If A is an array \vobject\v302., an array value, or a \vconstrained array subtype\v321., the basic operations also include the \vattributes\v405. listed below. These attributes are not allowed for an \vunconstrained array type\v321.. The argument N used in the attribute \vdesignators\v601. for the N-th \vdimension\v321. of an array must be a \vstatic expression\v422. of type universal_integer. The value of N must be positive (nonzero) and no greater than the dimensionality of the array. A'FIRST Yields the lower bound of the first \vindex\v321. range. The value of this attribute has the same type as this lower bound. A'FIRST(N) Yields the lower bound of the N-th index range. The value of this attribute has the same type as this lower bound. A'LAST Yields the upper bound of the first index range. The value of this attribute has the same type as this upper bound. A'LAST(N) Yields the upper bound of the N-th index range. The value of this attribute has the same type as this upper bound. A'RANGE Yields the first index range, that is, the range A'FIRST .. A'LAST. A'RANGE(N) Yields the N-th index range, that is, the range A'FIRST(N) .. A'LAST(N). A'LENGTH Yields the number of values of the first index range (zero for a \vnull range\v310.). The value of this attribute is of the type universal_integer. A'LENGTH(N) Yields the number of values of the N-th index range (zero for a null range). The value of this attribute is of the \vtype universal_integer\v314.. In addition, the attribute T'BASE is defined for an array type or subtype T (see 3.3.3); the attribute T'SIZE is defined for an array type or subtype T, and the attributes A'SIZE and A'ADDRESS are defined for an array object A (see 13.7.2). Besides the basic operations, the operations of an array type include the predefined comparison for equality and inequality, unless the array type is limited. For one-dimensional arrays, the operations include \vcatenation\v411., unless the array \vtype is limited\v708.; if the component type is a discrete type, the operations also include all predefined \vrelational operators\v411.; if the component type is a boolean type, then the operations also include the unary logical negation \voperator not\v411., and the \vlogical operators\v411.. Examples (using arrays declared in the examples of section 3.6.1): -- FILTER'FIRST = 0 FILTER'LAST = 31 FILTER'LENGTH = 32 -- RECTANGLE'LAST(1) = 20 RECTANGLE'LAST(2) = 30 \uNotes:\n The attributes A'FIRST and A'FIRST(1) yield the same value. A similar relation exists for the attributes A'LAST, A'RANGE, and A'LENGTH. The following relations are satisfied (except for a null array) by the above attributes if the index type is an integer type: A'LENGTH = A'LAST - A'FIRST + 1 A'LENGTH(N) = A'LAST(N) - A'FIRST(N) + 1 An array type is limited if its component type is limited (see 7.4.4). 3.6.3 \uThe Type String\n The values of the predefined type STRING are one-dimensional arrays of the predefined \vtype CHARACTER\v312., indexed by values of the predefined subtype POSITIVE: \usubtype\n POSITIVE \uis\n INTEGER \urange\n 1 .. INTEGER'LAST; \utype\n STRING \uis array\n(POSITIVE \urange\n <>) \uof\n CHARACTER; \uExamples:\n STARS : STRING(1 .. 120) := (1 .. 120 => '*' ); QUESTION : \uconstant\n STRING := "HOW MANY CHARACTERS?"; -- QUESTION'FIRST = 1, QUESTION'LAST = 20 (the number of characters) ASK_TWICE : \uconstant\n STRING := QUESTION & QUESTION; NINETY_SIX : \uconstant\n WOMAN := "XCVI"; -- see 3.6 \uNotes:\n String literals (see 2.6 and 4.2) are basic operations applicable to the \vtype\v321. STRING and to any other one-dimensional array type whose \vcomponent\v321. type is a character type. The \vcatenation operator\v411. is a \vpredefined\v411. \voperator\v411. for the type STRING and for one-dimensional array types; it is represented as &. The relational operators <, <=, >, and >= are defined for values of these types, and correspond to \vlexicographic order\v413. (see 4.5.2). 3.7 \uRecord Types\n A record \vobject\v302. is a composite object consisting of named \vcomponents\v305.. The value of a record object is a \vcomposite value\v305. consisting of the values of its components. record_type_definition ::= \urecord\n component_list \uend record\n component_list ::= component_declaration {component_declaration} | {component_declaration} \vvariant_part\v328. | \unull\n; component_declaration ::= \videntifier_list\v302. : component_subtype_definition [:= expression]; component_subtype_definition ::= subtype_indication Each component \vdeclaration\v301. declares a component of the record type. Besides components declared by component declarations, the components of a record type include any components declared by \vdiscriminant\v305. specifications of the record type declaration. The identifiers of all components of a record type must be distinct. The use of a \vname\v401. that denotes a record component other than a discriminant is not allowed within the record type definition that declares the component. A component declaration with several identifiers is equivalent to a sequence of single component declarations, as explained in section 3.2. Each single component declaration declares a record component whose subtype is specified by the component subtype definition. If a component declaration includes the \vassignment compound delimiter\v202. followed by an \vexpression\v410., the expression is the default expression of the record component; the default expression must be of the type of the component. Default expressions are not allowed for components that are of a \vlimited type\v708.. If a record type does not have a \vdiscriminant part\v325., the same components are present in all values of the type. If the component list of a record type is defined by the reserved word null and there is no discriminant part, then the record type has no components and all records of the type are null records. The \velaboration\v333. of a record type definition creates a record type; it consists of the elaboration of any corresponding (single) component declarations, in the order in which they appear, including any component declaration in a variant part. The elaboration of a component declaration consists of the elaboration of the component subtype definition. For the elaboration of a component subtype definition, if the \vconstraint\v305. does not \vdepend on a discriminant\v326. (see 3.7.1), then the subtype indication is elaborated. If, on the other hand, the constraint depends on a discriminant, then the elaboration consists of the evaluation of any included expression that is not a discriminant. Examples of record type declarations: \utype\n DATE \uis\n \urecord\n DAY : INTEGER \urange\n 1 .. 31; MONTH : MONTH_NAME; YEAR : INTEGER \urange\n 0 .. 4000; \uend record\n; \utype\n COMPLEX \uis\n \urecord\n RE : REAL := 0.0; IM : REAL := 0.0; \uend record\n; Examples of record variables: TOMORROW, YESTERDAY : DATE; A, B, C : COMPLEX; -- both components of A, B, and C are implicitly initialized to zero \uNotes:\n The default expression of a record component is implicitly evaluated by the elaboration of the declaration of a record object, in the absence of an explicit initialization (see 3.2.1). If a component declaration has several identifiers, the expression is evaluated once for each such component of the object (since the declaration is equivalent to a sequence of single component declarations). Unlike the components of an array, the components of a record need not be of the same type. More details: 3.7.1 \vDiscriminants\v326. 3.7.2 \vDiscriminant Constraints\v327. 3.7.3 \vVariant Parts\v328. 3.7.4 \vOperations of Record Types\v329. 3.7.1 \uDiscriminants\n A discriminant part specifies the discriminants of a type. A discriminant of a record is a \vcomponent of the record\v325.. The type of a discriminant must be discrete. discriminant_part ::= (discriminant_specification {; discriminant_specification}) discriminant_specification ::= identifier_list : type_mark [:= expression] A discriminant part is only allowed in the type \vdeclaration\v301. for a record type, in a \vprivate type\v704. declaration or an \vincomplete type\v331. \vdeclaration\v331. (the corresponding full declaration must then declare a \vrecord type\v325.), and in the \vgeneric parameter declaration\v1201. for a formal private type. A discriminant specification with several \videntifiers\v203. is equivalent to a sequence of single discriminant specifications, as explained in section 3.2. Each single discriminant specification declares a discriminant. If a discriminant specification includes the \vassignment compound delimiter\v202. followed by an expression, the expression is the default expression of the discriminant; the default expression must be of the type of the discriminant. Default expressions must be provided either for all or for none of the discriminants of a discriminant part. The use of the name of a discriminant is not allowed in default expressions of a discriminant part if the specification of the discriminant is itself given in the discriminant part. Within a record type definition the only allowed uses of the name of a discriminant of the record type are: in the default expressions for record components; in a variant part as the discriminant name; and in a component subtype definition, either as a bound in an \vindex constraint\v322., or to specify a discriminant value in a discriminant constraint. A discriminant name used in these component subtype definitions must appear by itself, not as part of a larger expression. Such component subtype definitions and such constraints are said to depend on a discriminant. A component is said to depend on a discriminant if it is a record component declared in a variant part, or a record component whose component subtype definition depends on a discriminant, or finally, one of the \vsubcomponents\v305. of a component that itself depends on a discriminant. Each record value includes a value for each discriminant specified for the record type; it also includes a value for each record component that does not depend on a discriminant. The values of the discriminants determine which other component values are in the record value. Direct \vassignment\v502. to a discriminant of an object is not allowed; furthermore a discriminant is not allowed as an actual parameter of mode in out or out, or as a generic actual parameter of mode in out. The only allowed way to change the value of a discriminant of a variable is to assign a (complete) value to the variable itself. Similarly, an assignment to the variable itself is the only allowed way to change the constraint of one of its components, if the component subtype definition depends on a discriminant of the variable. The elaboration of a discriminant part has no other effect. \uExamples:\n \utype\n BUFFER(SIZE : BUFFER_SIZE := 100) \uis\n -- see 3.5.4 \urecord\n POS : BUFFER_SIZE := 0; VALUE : STRING(1 .. SIZE); \uend record\n; \utype\n SQUARE(SIDE : INTEGER) \uis\n \urecord\n MAT : MATRIX(1 .. SIDE, 1 .. SIDE); -- see 3.6 \uend record\n; \utype\n DOUBLE_SQUARE(NUMBER : INTEGER) \uis\n \urecord\n LEFT : SQUARE(NUMBER); RIGHT : SQUARE(NUMBER); \uend record\n; \utype\n ITEM(NUMBER : POSITIVE) \uis\n \urecord\n CONTENT : INTEGER; -- no component depends on the discriminant \uend record\n; 3.7.2 \uDiscriminant Constraints\n A discriminant constraint is only allowed in a \vsubtype\v305. indication, after a type mark. This type mark must denote either a type with discriminants, or an \vaccess type\v330. whose \vdesignated type\v330. is a type with \vdiscriminants\v305.. A discriminant constraint specifies the values of these discriminants. discriminant_constraint ::= (discriminant_association {, discriminant_association}) discriminant_association ::= [discriminant_simple_name {| discriminant_simple_name} =>] expression Each discriminant association associates an \vexpression\v410. with one or more discriminants. A discriminant association is said to be named if the discriminants are specified explicitly by their \vnames\v401.; it is otherwise said to be positional. For a positional association, the (single) discriminant is implicitly specified by position, in textual order. Named associations can be given in any order, but if both positional and named associations are used in the same discriminant constraint, then positional associations must occur first, at their normal position. Hence once a named association is used, the rest of the discriminant constraint must use only named associations. For a named discriminant association, the discriminant names must denote discriminants of the type for which the discriminant constraint is given. A discriminant association with more than one discriminant name is only allowed if the named discriminants are all of the same type. Furthermore, for each discriminant association (whether named or positional), the expression and the associated discriminants must have the same type. A discriminant constraint must provide exactly one value for each discriminant of the type. A discriminant constraint is \vcompatible\v307. with the type denoted by a type mark, if and only if each discriminant value belongs to the subtype of the corresponding discriminant. In addition, for each \vsubcomponent\v305. whose \vcomponent subtype specification\v325. \vdepends on a \v326. \vdiscriminant\v326., the discriminant value is substituted for the discriminant in this component subtype specification and the compatibility of the resulting subtype indication is checked. A \vcomposite value\v305. satisfies a discriminant constraint if and only if each discriminant of the composite value has the value imposed by the discriminant constraint. The initial values of the discriminants of an \vobject\v302. of a type with discriminants are determined as follows: - For a \vvariable\v303. declared by an object declaration, the subtype indication of the corresponding object declaration must impose a discriminant constraint unless \vdefault expressions\v325. exist for the discriminants; the discriminant values are defined either by the constraint or, in its absence, by the default expressions. The same requirement exists for the subtype indication of a \vcomponent\v325. \vdeclaration\v325., if the type of the record component has discriminants; and for the component subtype indication of an \varray type\v321., if the type of the array components is a type with discriminants. - For a constant declared by an object declaration, the values of the discriminants are those of the initial value if the subtype of the constant is unconstrained; they are otherwise defined by this subtype (in the latter case, an exception is raised if the initial value does not belong to this subtype). The same rule applies to a generic parameter of \vmode in\v601.. - For an object designated by an access value, the discriminant values must be defined by the \vallocator\v421. that creates the object. (The allocated object is constrained with the corresponding discriminant values.) - For a \vformal parameter\v601. of a \vsubprogram\v600. or \ventry\v905., the discriminants of the formal parameter are initialized with those of the corresponding \vactual parameter\v607.. (The formal parameter is constrained if the corresponding actual parameter is constrained, and in any case if the mode is in or if the subtype of the formal parameter is constrained.) - For a \vrenaming declaration\v805. and for a \vgeneric formal parameter\v1201. of mode in out, the discriminants are those of the renamed object or of the corresponding \vgeneric actual parameter\v1206.. For the \velaboration\v333. of a discriminant constraint, the expressions given in the discriminant associations are evaluated in some order that is not defined by the language; the expression of a named association is evaluated once for each named discriminant. Examples (using types declared in the previous section): 01 LARGE : BUFFER(200); -- constrained, always 200 characters (explicit discriminant value) MESSAGE : BUFFER; -- unconstrained, initially 100 characters (default discriminant value) BASIS : SQUARE(5); -- constrained, always 5 by 5 ILLEGAL : SQUARE; -- illegal, a SQUARE must be constrained Note: The above rules and the rules defining the elaboration of an object declaration (see 3.2) ensure that discriminants always have a value. In particular, if a discriminant constraint is imposed on an object declaration, each discriminant is initialized with the value specified by the constraint. Similarly, if the subtype of a component has a discriminant constraint, the discriminants of the component are correspondingly initialized. 3.7.3 \uVariant Parts\n A \vrecord type\v325. with a variant part specifies alternative lists of \vcomponents\v305.. Each variant defines the components for the corresponding value or values of the discriminant. variant_part ::= \ucase\n discriminant_simple_name \uis\n variant {variant} \uend case\n; variant ::= \uwhen\n choice {| choice} => \vcomponent_list\v325. choice ::= \vsimple_expression\v410. | \vdiscrete_range\v321. | \uothers\n | component_simple_name Each variant starts with a list of choices which must be of the same type as the \vdiscriminant\v305. of the variant part. The type of the discriminant of a variant part must not be a \vgeneric formal type\v1201.. If the \vsubtype\v305. of the discriminant is static, then each value of this subtype must be represented once and only once in the set of choices of the variant part, and no other value is allowed. Otherwise, each value of the \v(base) type\v305. of the discriminant must be represented once and only once in the set of choices. The simple expressions and discrete \vranges\v310. given as choices in a variant part must be static. A choice defined by a discrete range stands for all values in the corresponding range (none if a \vnull range\v310.). The choice others is only allowed for the last variant and as its only choice; it stands for all values (possibly none) not given in the choices of previous variants. A component \vsimple name\v401. is not allowed as a choice of a variant (although it is part of the syntax of choice). A record value contains the values of the components of a given variant if and only if the discriminant value is equal to one of the values specified by the choices of the variant. This rule applies in turn to any further variant that is, itself, included in the component list of the given variant. If the component list of a variant is specified by null, the variant has no components. Example of record type with a variant part: \utype\n DEVICE \uis\n (PRINTER, DISK, DRUM); \utype\n STATE \uis\n (OPEN, CLOSED); \utype\n PERIPHERAL(UNIT : DEVICE := DISK) \uis\n \urecord\n STATUS : STATE; \ucase\n UNIT \uis\n \uwhen\n PRINTER => LINE_COUNT : INTEGER \urange\n 1 .. PAGE_SIZE; \uwhen others\n => CYLINDER : CYLINDER_INDEX; TRACK : TRACK_NUMBER; \uend case\n; \uend record\n; Examples of record subtypes: \usubtype\n DRUM_UNIT \uis\n PERIPHERAL(DRUM); \usubtype\n DISK_UNIT \uis\n PERIPHERAL(DISK); Examples of constrained record ariables: WRITER : PERIPHERAL(UNIT => PRINTER); ARCHIVE : DISK_UNIT; Note: Choices with discrete values are also used in case statements and in \varray\v409. \vaggregates\v409.. Choices with component simple names are used in record aggregates. 3.7.4 \uOperations of Record Types\n The \vbasic operations\v308. of a \vrecord type\v325. include the operations involved in \vassignment\v502. and aggregates (unless the type is limited), membership tests, selection of record components, qualifications, and type \vconversion\v419. (for \vderived types\v309.) For any \vobject\v303. A of a type with \vdiscriminants\v305., the basic \voperations\v305. also include the following \vattribute\v405.: A'CONSTRAINED Yields the value TRUE if the discriminant constraint applies to the object A, or if the object is a \vconstant\v303. (including a formal parameter or generic formal parameter of \vmode\v303. in); yields the value FALSE otherwise. If A is a generic formal parameter of mode in out, or if A is a formal parameter of mode in out or out and the type mark given in the corresponding parameter specification denotes an unconstrained type with discriminants, then the value of this attribute is obtained from that of the corresponding \vactual parameter\v607.. The value of this attri- bute is of the predefined type \vBOOLEAN\v313.. In addition, the attributes T'BASE and T'SIZE are defined for a record type or subtype T (see 3.3.3); the attributes A'SIZE and A'ADDRESS are defined for a record object A (see 13.7.2). Besides the basic operations, the operations of a record type include the predefined comparison for equality and inequality, unless the type is limited. Note: A record type is limited if the type of any of its components is limited (see 7.4.2). 3.8 \uAcess Types\n An object declared by an object declaration is created by the \velaboration\v333. of the object declaration and is denoted by a simple \vname\v401. or by some other form of name. In contrast, there are objects that are created by the eval- uation of \vallocators\v421. (see 4.8) and that have no simple name. Access to such an object is achieved by an access value returned by an allocator; the access value is said to designate the object. access_type_definition ::= \uaccess\n subtype_indication For each access type, there is a \vliteral\v406. null which has a null access value designating no object at all. The null value of an access type is the default initial value of the type. Other values of an access type are obtained by evaluation of a special operation of the type called an allocator. Each such access value designates an object of the \vsubtype\v305. defined by the \vsubtype indication\v307. of the access type definition; this subtype is called the designated subtype; the base type of this subtype is called the designated type. The objects designated by the values of an access type form a collection implicitly associated with the type. The elaboration of an access type definition consists of the elaboration of the subtype indication and creates an access type. If an access object is \vconstant\v303., the constrained access value cannot be changed and always designates the same object. On the other hand, the value of the designated object need not remain the same (\vassignment\v502. to the designated object is allowed unless the designated \vtype is limited\v708.). The only forms of contraint that are allowed after the name of an access type in a subtype indication are index \vconstraints\v305. and \vdiscriminant\v327. \vconstraints\v327.. (See sections 3.6.1 and 3.7.2 for the rules applicable to these subtype indications.) An access value belongs to a corresponding subtype of an access type either if the access value is the null value or if the value of the designated object satisfies the constraint. \uExamples:\n \utype\n FRAME \uis access\n MATRIX; -- see 3.6 \utype\n BUFFER_NAME \uis access\n BUFFER -- see 3.7.1 \uNotes:\n An access value delivered by an allocator can be assigned to several access objects. Hence it is possible for an object created by an allocator to be designated by more than one \vvariable\v303. or constant of the access type. An access value can only designate an object created by an allocator; in particular, it cannot designate an object declared by an object declaration. If the type of the objects designated by the access values is an \varray type\v321. or a type with discriminants, these objects are constrained with either the array bounds or the discriminant values supplied implicitly or explicity for the corresponding allocators (see 4.8). Access values are called pointers of references in some other languages. More details: 3.8.1 \vIncomplete Type Declarations\v331. 3.8.2 \vOperations of Access Types\v332. 3.8.1 \uIncomplete Type Declarations\n There are no particular limitations on the \vdesignated\v330. type of an access type. In particular, the type of a \vcomponent\v305. of the designated type can be another \vaccess type\v330., or even the same access type. This permits mutually dependent and recursive access types. Their declarations require a prior incomplete (or private) type declaration for one or more types. incomplete_type_declaration ::= type identifier [discriminant_part]; For each incomplete type declaration, there must be a corresponding declaration of a type with the same identifier. The corresponding declaration must be either a full type declaration or the declarations of a task type. In the rest of this section, explanations are given in terms of full type declarations; the same rules apply also to declarations of task types. If the incomplete type declaration occurs immediately within either a declarative part or the visible part of a package specification, then the full type declaration must occur later and immediately within this declarative part or visible part. If the incomplete type declaration occurs immediately within private part of a package, then the full type declaration must occur later and immediately within either the private part itself, or the declarative part of the corresponding package body. A \vdiscriminant part\v326. must be given in the full type declaration if and only if one is given in the incomplete type declaration; if discriminant parts are given, then they must \vconform\v604. (see 6.3.1 for the conformance rules). Prior to the end of the full type declaration, the only allowed use of a \vname\v401. that denotes a type declared by an incomplete type declaration is as the \vtype mark\v307. in the subtype indication of an \vaccess type definition\v330.; the only form of \vconstraint\v305. allowed in this subtype indication is a \vdiscriminant constraint\v327.. The \velaboration\v333. of an incomplete type \vdeclaration\v301. creates a type. If the incomplete type declaration has a discriminant part, this elaboration includes that of the discriminant part: in such a case, the discriminant part of the full type declaration is not elaborated. Example of a recursive type: \utype\n CELL; -- incomplete type declaration \utype\n LINK \uis access\n CELL; \utype\n CELL \uis\n \urecord\n VALUE : INTEGER; SUCC : LINK; PRED : LINK; \uend record\n; HEAD : LINK := \unew\n CELL'(O, \unull\n, \unull\n); NEXT : LINK := HEAD.SUCC; Examples of mutually dependent access types: \utype\n PERSON(SEX : GENDER); -- incomplete type declaration \utype\n CAR; -- incomplete type declaration \utype\n PERSON_NAME \uis access\n PERSON; \utype\n CAR_NAME \uis access\n CAR; \utype\n CAR \uis\n \urecord\n NUMBER : INTEGER; OWNER :PERSON_NAME; \uend record\n; \utype\n PERSON(SEX : GENDER) \uis\n \urecord\n NAME : STRING(1 .. 20); BIRTH : DATE; AGE : INTEGER \urange\n 0 .. 130; VEHICLE : CAR_NAME; \ucase\n SEX \uis\n \uwhen\n M => WIFE : PERSON_NAME(SEX => F); \uwhen\n F => HUSBAND : PERSON_NAME(SEX => M); \uend case\n; \uend record\n; MY_CAR, YOUR_CAR, NEXT_CAR : CAR_NAME; -- implicitly initialized with null value 3.8.2 \uOperations of Access Types\n The basic \voperations\v305. of an \vaccess type\v330. include the operations involved in \vassignment\v502., \vallocators\v421. for the access type, membership tests, qualification, explicit \vconversion\v419., and the \vliteral\v406. null. If the \vdesignated type\v330. is a type with \vdiscriminants\v305., the basic operations include the selection of the corresponding discriminants; if the designated type is a \vrecord type\v325., they include the selection of the corresponding components; if the designated type is an \varray type\v321., they include the formation of \vindexed components\v402. and slices; if the designated type is a \vtask type\v901., they include selection of entries and entry families. Furthermore, the basic operations include the formation of a \vselected\v404. \vcomponent\v404. with the \vreserved word\v404. all (see 4.1.3). If the designated type is an array type, the basic operations include the \vattributes\v405. that have the \vattribute designators\v405. FIRST, LAST, RANGE, and LENGTH (likewise, the attribute designators of the N-th dimension). The prefix of each of these attributes must be a value of the access type. These attributes yield the corresponding characteristics of the designated \vobject\v303. (see 3.6.2). If the designated type is a task type, the \vbasic operations\v308. include the attributes that have the attribute designators TERMINATED and CALLABLE (see 9.9). The prefix of each of these attributes must be a value of the access type. These attributes yield the corresponding characteristics of the designated task objects. In addition, the attribute T'BASE (see 3.3.3) and the representation attributes T'SIZE and T'STORAGE_SIZE (see 13.7.2) are defined for an access type or subtype T; the attributes A'SIZE and A'ADDRESS are defined for an access object A (see 13.7.2). Besides the basic operations, the operations of an access type include the predefined comparison for equality and inequality. 3.9 \uDeclarative Parts\n A declarative part contains declarative items (possibly none). declarative_part ::= {basic_declarative_item} {later_declarative_item} basic_declarative_item ::= basic_declaration | representation_clause | use_clause later_declarative_item ::= \ubody\n | subprogram_declaration | package_declaration | task_declaration | generic_declaration | use_clause | generic_instantiation \ubody\n ::= proper_body | body_stub proper_body ::= subprogram_body | package_body | task_body The elaboration of a declarative part consists of the elaboration of the declarative items, if any, in the order in which they are given in the declarative part. After its elaboration, a declarative item is said to be elaborated. Prior to the completion of its elaboration (including before the elaboration), the declarative item is not yet elaborated. For several forms of declarative item, the language rules (in particular \vscope\v802. and \vvisibility\v803. rules) are such that it is either impossible or illegal to use an entity before the elaboration of the declarative item that declares this entity. For example, it is not possible to use the name of a \vtype\v305. for an object declaration if the corresponding type declaration is not yet elaborated. In the case of bodies, the following checks are performed: - For a \vsubprogram call\v606., a check is made that the body of the subprogram is already elaborated. - For the \vactivation\v903. of a task, a check is made that the body of the corresponding task unit is already elaborated. - For the \vinstantiation\v1206. of a generic unit that has a body, a check is made that this body is already elaborated. The exception \vPROGRAM_ERROR\v1101. is raised if any of these checks fails. If a subprogram declaration, a package declaration, a task declaration, or a generic declaration is a declarative item of a given declarative part, then the body (if there is one) of the program unit declared by the declarative item must itself be a declarative item of this declarative part (and must appear later). If the body is a body stub, then a separately compiled subunit containing the corresponding proper body is required for the program unit (see 10.2). 4. \u Names and Expressions\n The rules applicable to the different forms of name and expression, and to their evaluation, are given in this chapter. More details: 4.1 \vNames\v401. 4.2 \vLiterals\v406. 4.3 \vAggregates\v407. 4.4 \vExpressions\v410. 4.5 \vOperators and Expression Evaluation\v411. 4.6 \vType Conversions\v419. 4.7 \vQualified Expressions\v420. 4.8 \vAllocators\v421. 4.9 \vStatic Expressions and Static Subtypes\v422. 4.10 \vUniversal Expression\v423. 4.1 \uNames\n Names can denote declared entities, whether declared explicitly or implicitly (see 3.1). Names can also denote objects \vdesignated\v330. by access values; subcomponents and \vslices\v403. of objects and values; single entries, \ventry\v905. families, and entries in families of entries. Finally, names can denote \vattributes\v405. of any of the foregoing. name ::= simple_name | character_literal | operator_symbol | \vindexed_component\v402. | slice | \vselected_component\v404. | attribute simple_name ::= identifier prefix ::= name | function_call A simple name for an \ventity\v301. is either the \videntifier\v203. associated with the entity by its \vdeclaration\v301., or another identifier associated with the entity by a \vrenaming declaration\v805.. Certain forms of name (indexed and selected \vcomponents\v305., slices, and attributes) include a prefix that is either a name or a \vfunction call\v606.. If the \vtype\v305. of a prefix is an \vaccess type\v330., then the prefix must not be a name that denotes a \vformal parameter\v601. of \vmode\v601. out or a \vsubcomponent\v305. thereof. If the prefix of a name is a function call, then the name denotes a component, a slice, an attribute, an entry, or an \ventry family\v905., either of the result of the function call, or (if the result is an \vaccess value\v330.) of the \vobject\v303. designated by the result. A prefix is said to be appropriate for a type in either of the following cases: - The type of the prefix is the type considered. - The type of the prefix is an access type whose \vdesignated type\v330. is the type considered. The \vevaluation\v411. of a name determines the entity denoted by the name. This evaluation has no other effect for a name that is a simple name, a \vcharacter literal\v207., or an \voperator symbol\v601.. The evaluation of a name that has a prefix includes the evaluation of the prefix, that is, of the corresponding name or function call. If the type of the prefix is an access type, the evaluation of the prefix includes the determination of the object designated by the corresponding access value; the \vexception CONSTRAINT_ERROR\v1101. is raised if the value of the prefix is a \vnull access value\v330., except in the case of the prefix of a representation attribute (see 13.7.2). Examples of simple names: PI -- the simple name of a number (see 3.2.2) LIMIT -- the simple name of a constant (see 3.2.1) COUNT -- the simple name of a scalar variable (see 3.2.1) BOARD -- the simple name of an array variable (see 3.6.1) MATRIX -- the simple name of a type (see 3.6) RANDOM -- the simple name of a function (see 6.1) ERROR -- the simple name of an exception (see 11.1) More details: 4.1.1 \vIndexed Components\v402. 4.1.2 \vSlices\v403. 4.1.3 \vSelected Components\v404. 4.1.4 \vAttributes\v405. 4.1.1 \uIndexed Components\n An indexed \vcomponent\v305. denotes either a \vcomponent of an array\v321. or an \ventry\v905. in a family of entries. indexed_component ::= prefix(expression {, expression}) In the case of a component of an array, the prefix must be \vappropriate for\v401. \van array type\v401.. The \vexpressions\v410. specify the \vindex\v321. values for the component; there must be one such expression for each index position of the \varray\v321. \vtype\v321.. In the case of an entry in a family of entries, the prefix must be a \vname\v401. that denotes an \ventry family\v905. of a \vtask object\v902., and the expression (there must be exactly one) specifies the index value for the individual entry. Each expression must be of the type of the corresponding index. For the \vevaluation\v411. of an indexed component, the prefix and the expressions are evaluated \vin some order\v108. that is not defined by the language. The exception \vCONSTRAINT_ERROR\v1101. is raised if an index value does not belong to the range of the corresponding index of the prefixing array or entry family. Examples of indexed components: MY_SCHEDULE(SAT) -- a component of a one-dimensional array (s. 3.6.1) PAGE(10) -- a component of a one-dimensional array (see 3.6) BOARD(M, J + 1) -- a component of a two-dimensional array (s. 3.6.1) PAGE(10)(20) -- a component of a component (see 3.6) REQUEST(MEDIUM) -- an entry in a family of entries (see 9.5) NEXT_FRAME(L)(M, N) -- a component of a \vfunction call\v606. (see 6.1) Notes on the \uExamples:\n Distinct notations are used for components of multidimensional arrays (such as BOARD) and arrays of arrays (such as PAGE). The components of an array of arrays are arrays and can therefore be indexed. Thus PAGE(10)(20) denotes the 20th component of PAGE(10). In the last example NEXT_FRAME(L) is a function call returning an access value which designates a two-dimensional array. 4.1.2 \uSlices\n A slice denotes a one-dimensional \varray\v321. formed by a sequence of consecutive \vcomponents\v305. of a one-dimensional array. A slice of a \vvariable\v303. is a variable; a slice of a \vconstant\v303. is a constant; a slice of a value is a value. slice ::= prefix(\vdiscrete_range\v321.) The \vprefix\v401. of a slice must be \vappropriate for a one-dimensional array type\v401.. The \vtype\v305. of the slice is the \vbase type\v305. of this \varray type\v321.. \vThe bounds of\v322. \vthe discrete range\v322. define those of the slice and must be of the type of the \vindex\v321.; the slice is a null slice denoting a \vnull array\v322. if the discrete range is a \vnull range\v310.. For the \vevaluation\v411. of a \vname\v401. that is a slice, the prefix and the discrete range are evaluated in some order that is not defined by the language. The \vexception CONSTRAINT_ERROR\v1101. is raised by the evaluation of a slice, other than a null slice, if any of the bounds of the discrete range does not belong to the \vindex range\v321. of the prefixing array. (The bounds of a null slice need not \vbelong to the subtype\v305. of the index.) Examples of slices: STARS(1 .. 15) -- a slice of 15 characters (see 3.6.3) PAGE(10 .. 10 + SIZE) -- a slice of 1 + SIZE components (s. 3.6 & 3.2.1) PAGE(L)(A .. B) -- a slice of the array PAGE(L) (see 3.6) STARS(1 .. 0) -- a null slice (see 3.6.3) MY_SCHEDULE(WEEKDAY) -- bounds given by subtype (s. 3.6 & 3.5.1) STARS(5 .. 15)(K) -- same as STARS(K) (see 3.6.3) -- provided that K is in 5 .. 15 \uNotes:\n For a one-dimensional array A, the name A(N .. N) is a slice of one component; its type is the base type of A. On the other hand, A(N) is a component of the array A and has the corresponding component type. 4.1.3 \uSelected Components\n Selected components are used to denote \vrecord components\v325., entries, entry families, and objects \vdesignated\v330. by \vaccess values\v330.; they are also used as expanded names as described below. selected_component ::= prefix.selector selector ::= simple_name | \vcharacter_literal\v207. | Operator_symbol | \uall\n The following four forms of selected components are used to denote a \vdiscriminant\v305., a record component, an \ventry\v905., or an \vobject\v303. designated by an access value: (a) A discriminant: The selector must be a simple name denoting a discriminant of an object or value. The \vprefix\v401. must be \vappropriate for the type\v401. of this object or value. (b) A \vcomponent of a record\v325.: The selector must be a \vsimple name\v401. denoting a component of a record object or value. The prefix must be appropriate for the type of this object or value. For a component of a \vvariant\v328., a check is made that the values of the discriminants are such that the record has this component. The exception \vCONSTRAINT_ERROR\v1101. is raised if this check fails. (c) A single entry or an \ventry family\v905. of a \vtask\v900.: The selector must be a simple name denoting a single entry or an entry family of a task. The prefix must be appropriate for the type of this task. (d) An object designated by an access value: The selector must be the \vreserved word\v211. \uall\n. The value of the prefix must belong to an \vaccess type\v330.. A selected component of one of the remaining two forms is called an expanded name. In each case the selector must be either a simple name, a character literal, or an \voperator symbol\v601.. A \vfunction call\v606. is not allowed as the prefix of an expanded name. An expanded name can denote: (e) An \ventity\v301. declared in the \vvisible part\v328. of a \vpackage\v700.: The prefix must denote the package. The selector must be the simple name, character literal, or \voperator\v411. symbol of the entity. (f) An entity whose \vdeclaration\v301. \voccurs immediately\v801. within a named construct: The prefix must denote a construct that is either a \vprogram unit\v600., a \vblock statement\v507., a \vloop statement\v506., or an \vaccept statement\v905.. In the case of an accept statement, the prefix must be either the simple name of the entry or entry family, or an expanded name ending with such a simple name (that is, no \vindex\v321. is allowed). The selector must be the simple name, character literal, or operator symbol of an entity whose declaration occurs immediately within the construct. This form of expanded name is only allowed within the construct itself (including the body and any \vsubunits\v1004., in the case of a program unit). A name declared by a \vrenaming declaration\v805. is not allowed as the prefix. If the prefix is the name of a \vsubprogram\v600. or accept statement and if there is more than one visible enclosing subprogram or accept statement of this name, the expanded name is ambiguous, independently of the selector. If, according to the \vvisibility\v803. rules, there is at least one possible interpretation of the prefix of a selected component as the name of an enclosing subprogram or accept statement, then the only interpretations considered are those of rule (f), as expanded names (no interpretations of the prefix as a function call are then considered). The evaluation of a name that is a selected component includes the evaluation of the prefix. Examples of selected components: TOMORROW.MONTH -- a record component (see 3.7) NEXT_CAR.OWNER -- a record component (see 3.8.1) NEXT_CAR.OWNER.AGE -- a record component (see 3.8.1) WRITER.UNIT -- a record component (a discriminant) (see 3.7.3) MIN_CELL(H).VALUE -- a record component of the result (see 6.1 & 3.8.1) -- of the function call MIN_CELL(H) CONTROL.SEIZE -- an entry of the task CONTROL (see 9.1 and 9.2) POOL(K).WRITE -- an entry of the task POOL(K) (see 9.1 and 9.2) NEXT_CAR.\uall\n -- the object designated by -- the access \vvariable\v328. NEXT_CAR (see 3.8.1) Examples of expanded names: TABLE_MANAGER.INSERT -- a procedure of the visible part of a package (see 7.5) KEY_MANAGER."<" -- an operator of the visible part of a package (see 7.4.2) DOT_PRODUCT.SUM -- a variable declared in a \vprocedure body\v609. BUFFER.POOL -- a variable declared in a task unit (see 9.12) BUFFER.READ -- an entry of a task unit (see 9.12) SWAP.TEMP -- a variable declared in a block statement (s.5.6) STANDARD.BOOLEAN -- the name of a predefined type (see 8.6 and C) Note: For a record with components that are other records, the above rules imply that the simple name must be given at each level for the name of a subcomponent. For example, the name NEXT_CAR.OWNER.BIRTH.MONTH cannot be shortened (NEXT_CAR.OWNER.MONTH is not allowed). 4.1.4 Attributes An attribute denotes a \vbasic operation\v308. of an entity given by a \vprefix\v401.. attribute ::= prefix'attribute_designator attribute_designator ::= \vsimple_name\v401. [(\vuniversal_static_expression\v422.)] The applicable attribute designators depend on the prefix. An attribute can be a basic operation delivering a value; alternatively it can be a function, a \vtype\v305., or a range. The meaning of the prefix of an attribute must be determinable independently of the attribute designator and independently of the fact that it is the prefix of an attribute. The attributes defined by the language are summarized in Annex A. In addition, an implementation may provide implementation-defined attributes; their description must be given in Appendix F. The attribute designator of any implementation-defined attribute must not be the same as that of any language-defined attribute. The evaluation of a \vname\v401. that is an attribute consists of the evaluation of the prefix. \uNotes:\n The attribute designators DIGITS, DELTA, and RANGE have the same identifier as a \vreserved word\v211.. However, no confusion is possible since an attribute designator is always preceded by an apostrophe. The only predefined attribute designators that have a \vuniversal expression\v423. are those for certain operations of array types (see 3.6.2). Examples of attributes: COLOR'FIRST -- minimum value of the enumeration type COLOR (see 3.3.1 and 3.5) RAINBOW'BASE'FIRST -- same as COLOR'FIRST (see 3.3.2 and 3.3.3) REAL'DIGITS -- precision of the type REAL (see 3.5.7 and 3.5.8) BOARD'LAST(2) -- upper bound of the second dimension of BOARD (see 3.6.1 and 3.6.2) BOARD'RANGE(1) -- index range of the first dimension of BOARD (see 3.6.1 and 3.6.2) POOL(K)'TERMINATED -- TRUE if task POOL(K) is terminated (see 9.2 & 9.9) DATE'SIZE -- number of bits for records of type DATE (see 3.7 and 13.7.2) MESSAGE'ADDRESS -- address of the record variable MESSAGE (see 3.7.2 and 13.7.2) 4.2 \uLiterals\n A literal is either a \vnumeric literal\v204., an \venumeration literal\v311., the literal null, or a string literal. The evaluation of a literal yields the corresponding value. Numeric literals are the literals of the \vtypes\v305. \vuniversal_integer\v314. and \vuniversal_real\v316.. Enumeration literals include \vcharacter literals\v206. and yield values of the corresponding enumeration types. The literal null yields a \vnull access value\v330. which \vdesignates\v330. no \vobjects\v303. at all. A string literal is a basic operation that combines a sequence of characters into a value of a one-dimensional \varray\v321. of a \vcharacter type\v312.; the bounds of this array are determined according to the rules for positional array \vaggregates\v407. (see 4.3.2). For a \vnull string literal\v330., the upper bound is the predecessor, as given by the PRED attribute, of the lower bound. The evaluation of a null \vstring literal\v208. raises the exception \vCONSTRAINT_ERROR\v1101. if the lower bound does not have a predecessor (see 3.5.5). The type of a string literal and likewise the type of the literal null must be determinable solely from the context in which this literal appears, excluding the literal itself, but using the fact that the literal null is a value of an \vaccess type\v330., and similarly that a string literal is a value of a one-dimensional \varray type\v321. whose \vcomponent type\v305. is a character type. The character literals corresponding to the \vgraphic characters\v201. contained within a string literal must be visible at the place of the string literal (although these characters themselves are not used to determine the type of the string literal). \uExamples:\n 3.14159_26536 -- a \vreal literal\v204. 1_345 -- an \vinteger literal\v204. CLUBS -- an enumeration literal 'A' -- a character literal "SOME TEXT" -- a string literal 4.3 \uAggregates\n An aggregate is a \vbasic operation\v308. that combines \vcomponent\v305. values into a \vcomposite value\v305. of a \vrecord\v325. or \varray type\v321.. aggregate ::= (component_association {, component_association}) component_association ::= [\vchoice\v328. {| choice} => ] \vexpression\v410. Each component association associates an expression with components (possibly none). A component association is said to be named if the components are specified explicitly by choices; it is otherwise said to be positional. For a positional association, the (single) component is implicitly specified by position, in the order of the corresponding component declarations for record components, in \vindex\v321. order for array components. Named associations can be given in any order (except for the choice others), but if both positional and named associations are used in the same aggregate, then positional associations must occur first, at their normal position. Hence once a named association is used, the rest of the aggregate must use only named associations. Aggregates containing a single component association must always be given in named notation. Specific rules concerning component associations exist for \vrecord aggregates\v408. and \varray aggregates\v409.. Choices in component associations have the same syntax as in \vvariant parts\v328. (see 3.7.3). A choice that is a component \vsimple name\v401. is only allowed in a record aggregate. For a component association, a choice that is a \vsimple\v410. \vexpression\v410. or a \vdiscrete range\v321. is only allowed in an array aggregate; a choice that is a simple expression specifies the component at the corresponding index value; similarly a discrete range specifies the components at the index values in the range. The choice others is only allowed in a component association if the association appears last and has this single choice; it specifies all remaining components, if any. Each component of the value defined by an aggregate must be represented once and only once in the aggregate. Hence each aggregate must be complete and a given component is not allowed to be specified by more than one choice. The \vtype\v305. of an aggregate must be determinable solely from the context in which the aggregate appears, excluding the aggregate itself, but using the fact that this type must be composite and not limited. The type of an aggregate in turn determines the required type for each of its components. \uNotes:\n The above rule implies that the determination of the type of an aggregate cannot use any information from within the aggregate. In particular, this determination cannot use the type of the expression of a component association, or the form or the type of a choice. An aggregate can always be distinguished from an expression enclosed by parentheses: this is a consequence of the fact that named notation is required for an aggregate with a single component. More details: 4.3.1 \vRecord Aggregates\v408. 4.3.2 \vArray Aggregates\v409. 4.3.1 \uRecord Aggregates\n If the \vtype\v305. of an \vaggregate\v407. is a \vrecord type\v325., the \vcomponent names\v325. given as \vchoices\v328. must denote components (including discriminants) of the record type. If the choice others is given as a choice of a record aggregate, it must represent at least one component. A \vcomponent association\v407. with the choice others or with more than one choice is only allowed if the represented components are all of the same type. The \vexpression\v410. of a component association must have the type of the associated \vrecord\v325. \vcomponents\v325.. The value specified for a \vdiscriminant\v305. that governs a \vvariant part\v328. must be given by a \vstatic expression\v422. (note that this value determines which dependent components must appear in the record value). For the evaluation of a record aggregate, the expressions given in the component associations are \vevaluated\v411. \vin some order\v108. that is not defined by the language. The expression of a named association is evaluated once for each associated component. A check is made that the value of each \vsubcomponent\v305. of the aggregate belongs to the \vsubtype\v307. of this subcomponent. The \vexception CONSTRAINT_ERROR\v1101. is raised if this check fails. Example of a record aggregate with positional associations: (4, JULY, 1776) -- see 3.7 Examples of record aggregates with named associations: (DAY => 4, MONTH => JULY, YEAR => 1776) (MONTH => JULY, DAY => 4, YEAR => 1776) (DISK, CLOSED, TRACK => 5, CYLINDER => 12) -- see 3.7.3 (UNIT => DISK, STATUS => CLOSED, CYLINDER => 9, TRACK => 1) Example of component association with several choices: (VALUE => 0, SUCC|PRED => \unew\n CELL'(0, \unull\n, \unull\n)) -- see 3.8.1 -- The \vallocator\v421. is evaluated twice: SUCC and PRED designate different cells Note: For an aggregate with positional associations, discriminant values appear first since the \vdiscriminant part\v326. is given first in the record type declaration; they must be in the same order as in the discriminant part. 4.3.2 \uArray Aggregates\n If the \vtype\v305. of an \vaggregate\v407. is a one-dimensional \varray type\v321., then each \vchoice\v328. must specify values of the \vindex type\v321., and the \vexpression\v410. of each \vcomponent association\v407. must be of the \vcomponent type\v305.. If the type of an aggregate is a multidimensional array type, an n-dimensional aggregate is written as a one-dimensional aggregate, in which the expression specified for each component association is itself written as an (n-1)-dimensional aggregate which is called a subaggregate; the \vindex subtype\v321. of the one-dimensional aggregate is given by the first index position of the array type. The same rule is used to write a subaggregate if it is again multidimensional, using successive index positions. A string literal is allowed in a multidimensional aggregate at the place of a one-dimensional array of a character type. In what follows, the rules concerning array aggregates are formulated in terms of one-dimensional aggregates. Apart from a final component association with the single choice others, the rest (if any) of the component associations of an array aggregate must be either all positional or all named. A \vnamed association\v407. of an array aggregate is only allowed to have a choice that is not static, or likewise a choice that is a null range, if the aggregate includes a single component association and this component association has a single choice. An others choice is static if the applicable index \vconstraint\v305. is static. The bounds of an array aggregate that has an others choice are determined by the applicable \vindex constraint\v322.. An others choice is only allowed if the aggregate appears in one of the following contexts (which defines the applicable index constraint): (a) The aggregate is an \vactual parameter\v607., a generic actual parameter, the result expression of a \vfunction\v609., or the expression that follows an \vassignment compound delimiter\v502.. Moreover, the subtype of the corresponding formal parameter, generic \vformal parameter\v601., function result, or \vobject\v302. is a \vconstrained array subtype\v321.. For an aggregate that appears in such a context and contains an association with an others choice, named associations are allowed for other associations only in the case of a (nongeneric) actual parameter or function result. If the aggregate is a multidimensional array, this restriction also applies to each of its subaggregates. (b) The aggregate is the operand of a \vqualified expression\v420. whose type mark denotes a constrained array subtype. (c) The aggregate is the expression of the component association of an enclosing (array or record) aggregate. Moreover, if this enclosing aggregate is a multidimensional array aggregate then it is itself in one of these three contexts. The bounds of an array aggregate that does not have an others choice are determined as follows. For an aggregate that has named associations, the bounds are determined by the smallest and largest choices given. For a positional aggregate, the lower bound is determined by the applicable index constraint if the aggregate appears in one of the contexts (a) through (c); otherwise, the lower bound is given by S'FIRST where S is the index subtype; in either case, the upper bound is determined by the number of components. The evaluation of an array aggregate that is not a subaggregate proceeds in two steps. First, the choices of this aggregate and of its subaggregates, if any, are \vevaluated\v411. \vin some order\v108. that is not defined by the language. Second, the expressions of the component associations of the array aggregate are evaluated in some order that is not defined by the language; the expression of a named association is evaluated once for each associated component. The evaluation of a subaggregate consists of this second step (the first step is omitted since the choices have already been evaluated). For the evaluation of an aggregate that is not a \vnull array\v322., a check is made that the index values defined by choices belong to the corresponding index subtypes, and also that the value of each \vsubcomponent\v305. of the aggregate belongs to the subtype of this subcomponent. For an n-dimensional multidimensional aggregate, a check is made that all (n-1)-dimensional subaggregates have the same bounds. The exception \vCONSTRAINT_ERROR\v1101. is raised if any of these checks fails. Note: The allowed contexts for an array aggregate including an others choice are such that the bounds of such an aggregate are always known from the context. Examples of array aggregates with \vpositional associations\v407.: (7, 9, 5, 1, 3, 2, 4, 8, 6, 0) TABLE'(5, 8, 4, 1, others => 0) -- see 3.6 Examples of array aggregates with named associations: (1 .. 5 => (1 .. 8 => 0.0)) -- two-dimensional (1 .. N => \unew\n CELL) -- N new cells, in particular for N = 0 TABLE'(2 | 4 | 10 => 1, \uothers\n => 0) SCHEDULE'(MON .. FRI => TRUE, \uothers\n => FALSE) -- see 3.6 SCHEDULE'(WED | SUN => FALSE, \uothers\n => TRUE) Examples of two-dimensional array aggregates: -- Three aggregates for the same value of type MATRIX (see 3.6): ((1.1, 1.2, 1.3), (2.1, 2.2, 2.3)) (1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3)) (1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3)) Examples of aggregates as initial values: A : TABLE := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0); -- A(1)=7, A(10)= 8 B : TABLE := TABLE'(2 | 4 | 10 => 1, \uothers\n => 0); -- B(1)=0, B(10)=1 C : \uconstant\n MATRIX := (1 .. 5 => (1 .. 8 => 0.0)); -- C'FIRST(1)=1, C'LAST(2)=8 D : BIT_VECTOR(M .. N) := (M .. N => TRUE); -- see 3.6 E : BIT_VECTOR(M .. N) := (\uothers\n => TRUE); F : STRING(1 .. 1) := (1 => 'F'); -- a one component aggregate: same as "F" 4.4 \uExpressions\n An expression is a formula that defines the computation of a value. expression ::= \vrelation\v412. {and relation} | relation {and then relation} | relation {or relation} | relation {or else relation} | relation {xor relation} relation ::= simple_expression [\vrelational_operator\v411. simple_expression] | simple_expression [not] in \vrange\v310. | simple_expression [not] in \vtype_mark\v307. simple_expression ::= [\vunary_adding_operator\v411.] term {\vbinary_adding_operator\v411. term} term ::= factor {\vmultiplying_operator\v411. factor} factor ::= primary [** primary] | \uabs\n primary | not primary primary ::= \vnumeric_literal\v204. | \unull\n | \vaggregate\v407. | \vstring_literal\v208. | \vname\v401. | \vallocator\v421. | \vfunction_call\v606. | \vtype_conversion\v419. | \vqualified_expression\v420. | (expression) Each primary has a value and a \vtype\v305.. The only names allowed as primaries are named numbers; \vattributes\v405. that yield values; and names denoting \vobjects\v302. (the value of such a primary is the value of the object) or denoting values. Names that denote formal parameters of mode out are not allowed as primaries; names of their subcomponents are only allowed in the case of discriminants. The type of an expression depends only on the type of its constituents and on the \voperators\v411. applied; for an overloaded constituent or operator, the determination of the constituent type, or the identification of the appropriate operator, depends on the context. For each predefined operator, the operand and \vresult types\v601. are given in section 4.5. Examples of primaries: 4.0 -- \vreal literal\v204. PI -- \vnamed number\v302. (1 .. 10 => 0) -- \varray aggregate\v409. SUM -- \vvariable\v303. INTEGER'LAST -- attribute SINE(X) -- function call COLOR'(BLUE) -- qualified expression REAL(M*N) -- conversion (LINE_COUNT + 10) -- parenthesized expression Examples of expressions: VOLUME -- primary \unot\n DESTROYED -- factor 2*LINE_COUNT -- term -4.0 -- simple expression -4.0 + A -- simple expression B**2 - 4.0*A*C -- simple expression PASSWORD(1 .. 3) = "BWV" -- relation COUNT \uin\n SMALL_INT -- relation COUNT \unot in\n SMALL_INT -- relation INDEX = 0 \uor\n ITEM_HIT -- expression (COLD \uand\n SUNNY) \uor\n WARM -- expression (parentheses are required) A**(B**C) -- expression (parentheses are required) 4.5 \uOperators and Expression Evaluation\n The language defines the following six classes of operators. The corresponding operator symbols (except /=), and only those, can be used as \vdesignators\v601. in declarations of functions for user-defined operators. They are given in the order of increasing precedence. logical_operator ::= \uand\n | \uor\n | \uxor\n relational_operator ::= = | /= | < | <= | > | >= binary_adding_operator ::= + | - | & unary_adding_operator ::= + | - multiplying_operator ::= * | / | \umod\n | \urem\n highest_precedence_operator ::= ** | \uabs\n | \unot\n The \vshort-circuit control\v411. forms and then and or else have the same precedence as logical operators. The membership tests in and not in have the same precedence as relational operators. For a \vterm\v410., simple \vexpression\v410., \vrelation\v410., or expression, operators of higher precedence are associated with their operands before operators of lower precedence. In this case, for a sequence of operators of the same precedence level, the operators are associated in textual order from left to right; parentheses can be used to impose specific associations. The operands of a \vfactor\v410., of a term, of a \vsimple expression\v410., or of a relation, and the operands of an expression that does not contain a short-circuit control form, are evaluated \vin some order\v108. that is not defined by the language (but before application of the corresponding operator). The right operand of a short-circuit control form is evaluated if and only if the left operand has a certain value (see 4.5.1). For each form of type declaration, certain of the above operators are predefined, that is, they are \vimplicitly declared\v301. by the type declaration. For each such implicit operator declaration, the \vnames\v401. of the parameters are LEFT and RIGHT for binary operators; the single parameter is called RIGHT for unary adding operators and for the unary operators \uabs\n and \unot\n. The effect of the predefined operators is explained in subsections 4.5.1 through 4.5.7. The predefined operations on \vinteger types\v314. either yield the mathematically correct result or raise the exception \vNUMERIC_ERROR\v1101.. A predefined operation that delivers a result of an integer type (other than \vuniversal_integer\v314.) can only raise the exception NUMERIC_ERROR if the mathematical result is not a value of the type. The predefined operations on \vreal types\v316. yield results whose accuracy is defined in section 4.5.7. A predefined operation that delivers a result of a real type (other than \vuniversal_real\v316.) can only raise the exception NUMERIC_ERROR if the result is not within the \vrange\v310. of the \vsafe numbers\v316. of the type, as explained in section 4.5.7. Examples of precedence: \unot\n SUNNY \uor\n WARM -- same as (not SUNNY) or WARM X > 4.0 \uand\n Y > 0.0 -- same as (X > 4.0) \uand\n (Y > 0.0) -4.0*A**2 -- same as -(4.0 * (A**2)) \uabs\n(1 + A) + B -- same as (\uabs\n (1 + A)) + B Y**(-3) -- parentheses are necessary A / B * C -- same as (A/B)*C A + (B + C) -- evaluate B + C before adding it to A More details: 4.5.1 \vLogical Operators and Short Circuit Control Forms\v412. 4.5.2 \vRelational Operators and Membership Tests\v413. 4.5.3 \vAdding Operators\v414. 4.5.4 \vUnary Operators\v415. 4.5.5 \vMultiplying Operators\v416. 4.5.6 \vHighest Precedence Operations\v417. 4.5.7 \vAccuracy of Operations with Real Operands\v418. 4.5.1 \uLogical Operators and Short-circuit Control Forms\n The following logical \voperators\v411. are predefined for any boolean \vtype\v305. and any one-dimensional \varray type\v321. whose components are of a \vboolean type\v313.; in either case the two operands have the same type. Operator Operation Operand type Result type \uand\n conjunction any boolean type same bool. type array of boolean components same array type \uor\n inclusive disjunction any boolean type same bool. type array of boolean components same array type \uxor\n exclusive disjunction any boolean type same bool. type array of boolean components same array type The \voperations\v305. on arrays are performed on a component-by-component basis on matching components, if any (as for equality, see 4.5.2). The bounds of the resulting array are those of the left operand. A check is made that for each component of the left operand there is a matching component of the right operand, and vice versa. The \vexception CONSTRAINT_ERROR\v1101. is raised if this check fails. The short-circuit control forms and then and or else are defined for two operands of a boolean type and deliver a result of the same type. The left operand of a short-circuit control form is always evaluated first. If the left operand of an expression with the control form and then evaluates to FALSE, the right operand is not evaluated and the value of the expression is FALSE. If the left operand of an expression with the control form or else evaluates to TRUE, the right operand is not evaluated and the value of the expression is TRUE. If both operands are evaluated, and then delivers the same result as and, and or else delivers the same result as or. Note: The conventional meaning of the logical operators is given by the fol- lowing truth table: A B (A \uand\n B) (A or B) (A xor B) TRUE TRUE TRUE TRUE FALSE TRUE FALSE FALSE TRUE TRUE FALSE TRUE FALSE TRUE TRUE FALSE FALSE FALSE FALSE FALSE Examples of logical operators: SUNNY \uor\n WARM FILTER(1 .. 10) \uand\n FILTER(15 .. 24) -- see 3.6.1 Examples of short-circuit control forms: NEXT_CAR.OWNER /= \unull and then\n NEXT_CAR.OWNER.AGE > 25 -- see 3.8.1 N = 0 \uor else\n A(N) = HIT_VALUE 4.5.2 \uRelational Operators and Membership Tests\n The equality and inequality \voperators\v411. are \vpredefined\v411. for any \vtype\v305. that is not limited. The other relational operators are the ordering operators < (less than), <= (less than or equal), > (greater than), and >= (greater than or equal). The ordering operators are predefined for any \vscalar\v310. \vtype\v310., and for any discrete \varray type\v321., that is, a one-dimensional array type whose \vcomponents\v305. are of a \vdiscrete type\v310.. The operands of each predefined relational operator have the same type. The result type is the \vpredefined type BOOLEAN\v313.. The relational operators have their conventional meaning: the result is equal to TRUE if the corresponding relation is satisfied; the result is FALSE otherwise. The inequality operator gives the complementary result to the equality operator: FALSE if equal, TRUE if not equal. Operator \vOperation\v305. Operand type Result type = /= equality and inequality any type BOOLEAN < <= > >= test for ordering any scalar type BOOLEAN discrete array type BOOLEAN Equality for the discrete types is equality of the values. For real operands whose values are nearly equal, the results of the predefined relational operators are given in section 4.5.7. Two \vaccess values\v330. are equal either if they \vdesignate\v330. the same \vobject\v303., or if both are equal to the \vnull value\v330. of the access type. For two array values or two record values of the same type, the left operand is equal to the right operand if and only if for each component of the left operand there is a matching component of the right operand and vice versa; and the values of matching components are equal, as given by the predefined equality operator for the component type. In particular, two \vnull arrays\v322. of the same type are always equal; two \vnull records\v325. of the same type are always equal. For comparing two records of the same type, matching components are those which have the same \vcomponent identifier\v325.. For comparing two one-dimensional arrays of the same type, matching components are those (if any) whose index values match in the following sense: the lower bounds of the index \vranges\v310. are defined to match, and the \vsuccessors\v315. of matching indices are defined to match. For comparing two multidimensional arrays, matching components are those whose index values match in successive index positions. If equality is explicitly defined for a \vlimited type\v708., it does not extend to \vcomposite types\v305. having \vsubcomponents\v305. of the limited type (explicit definition of equality is allowed for such composite types). The ordering operators <, <=, >, and >= that are defined for discrete array types correspond to lexicographic order using the predefined order relation of the \vcomponent type\v305.. A null array is lexicographically less than any array having at least one component. In the case of nonnull arrays, the left operand is lexicographically less than the right operand if the first component of the left operand is less than that of the right; otherwise the left operand is lexicographically less than the right operand only if their first components are equal and the tail of the left operand is lexicographically less than that of the right (the tail consists of the remaining components beyond the first and can be null). The membership tests in and not in are predefined for all types. The result type is the predefined type BOOLEAN. For a membership test with a range, the \vsimple expression\v410. and the bounds of the range must be of the same scalar type; for a membership test with a \vtype mark\v307., the type of the simple expression must be the \vbase type\v305. of the type mark. The \vevaluation\v411. of the membership test in yields the result TRUE if the value of the simple expression is within the given range, or if this value \vbelongs to the\v305. \vsubtype\v305. denoted by the given type mark; otherwise this evaluation yields the result FALSE (for a value of a real type, see 4.5.7). The membership test not in gives the complementary result to the membership test in. \uExamples:\n X /= Y "" < "A" \uand\n "A" < "AA" -- TRUE "AA" < "B" \uand\n "A" < "A " -- TRUE MY_CAR = \unull\n -- true if MY_CAR has been set to null (see 3.8.1) MY_CAR = YOUR_CAR -- true if we both share the same car MY_CAR.\uall\n = YOUR_CAR.\uall\n -- true if the two cars are identical N \unot in\n 1 .. 10 -- range membership test TODAY \uin\n MON .. FRI -- range membership test TODAY \uin\n WEEKDAY -- subtype membership test (see 3.5.1) ARCHIVE \uin\n DISK_UNIT -- subtype membership test (see 3.7.3) \uNotes:\n No \vexception\v1100. is ever raised by a predefined relational operator or by a membership test, but an exception can be raised by the evaluation of the operands. If a \vrecord type\v325. has components that depend on discriminants, two values of this type have matching components if and only if their discriminants are equal. Two nonnull arrays have matching components if and only if the value of the attribute LENGTH(N) for each \vindex\v321. position N is the same for both. 4.5.3 \uBinary Adding Operators\n The binary adding \voperators\v411. + and - are predefined for any \vnumeric type\v310. and have their conventional meaning. The catenation operators & are predefined for any one-dimensional \varray type\v321. that is not limited. +-Operator | \vOperation\v305. Left operand \vtype\v305. Right operand type Result type +----------------------------------------------------------------------+ |+ | addition |any numeric type |same numeric type |same numeric type| | | | | | | |- |subtraction|any numeric type |same numeric type |same numeric type| | | | | | | |& |catenation |any array type |same array type |same array type | | | |any array type |the \vcomponent type\v305.|same array type | | | |the component type|any array type |same array type | | | |the component type|the component type|any array type | +----------------------------------------------------------------------+ For \vreal types\v316., the accuracy of the result is determined by the operand type (see 4.5.7). If both operands are one-dimensional arrays, the result of the catenation is a one-dimensional array whose length is the sum of the lengths of its operands, and whose components comprise the components of the left operand followed by the components of the right operand. The lower bound of this result is the lower bound of the left operand, unless the left operand is a \vnull array\v322., in which case the result of the catenation is the right operand. If either operand is of the component type of an array type, the result of the catenation is given by the above rules, using in place of this operand an array having this operand as its only component and having the lower bound of the \vindex subtype\v321. of the array type as its lower bound. The \vexception CONSTRAINT_ERROR\v1101. is raised by catenation if the upper bound of the result exceeds the \vrange of the index subtype\v322., unless the result is a null array. This exception is also raised if any operand is of the component type but has a value that does not belong to the component subtype. \uExamples:\n Z + 0.1 -- Z must be of a real type "A" & "BCD" -- catenation of two \vstring literals\v208. 'A' & "BCD" -- catenation of a \vcharacter literal\v207. and a string literal 'A' & 'A' -- catenation of two character literals 4.5.4 \uUnary Adding Operators\n The unary adding \voperators\v411. + and - are predefined for any \vnumeric type\v310. and have their conventional meaning. For each of these operators, the operand and the result have the same \vtype\v305.. Operator Operation Operand type Result type + identity any numeric type same numeric type - negation any numeric type same numeric type 4.5.5 \uMultiplying Operators\n The operators * and / are predefined for any integer and any \vfloating point\v317. \vtype\v317. and have their conventional meaning; the operators mod and rem are predefined for any \vinteger type\v314.. For each of these operators, the operands and the result have the same \vbase type\v305.. For floating point types, the accuracy of the result is determined by the operand type (see 4.5.7). Operator Operation Operand type Result type * multiplication any integer type same integer type any floating point same floating point type type / integer division any integer type same integer type floating division any floating point same floating point type type \nmod\n modulus any integer type same integer type \urem\n remainder any integer type same integer type Integer division and remainder are defined by the relation A = (A/B)*B + (A \urem\n B) where (A rem B) has the sign of A and an absolute value less than the absolute value of B. Integer division satisfies the identity (-A)/B = -(A/B) = A/(-B) The result of the modulus operation is such that (A mod B) has the sign of B and an absolute value less than the absolute value of B; in addition, for some integer value N, this result must satisfy the relation A = B*N + (A \umod\n B) For each \vfixed point type\v319., the following multiplication and division operators, with an operand of the predefined type INTEGER, are predefined. Operator Operation Left operand Right operand Result type type type * multiply any fixed point INTEGER same as left type INTEGER any fixed point same as right type / division any fixed point INTEGER same as left type Integer multiplication of fixed point values is equivalent to repeated addition. Division of a fixed point value by an integer does not involve a change in type but is approximate (see 4.5.7). Finally, the following multiplication and division operators are declared in the \vpredefined package STANDARD\v806.. These two special operators apply to operands of all fixed point types (it is a consequence of other rules that they cannot be renamed or given as generic \vactual parameters\v607.). Operator Operation Left operand Right operand Result type type type * multiply any fixed point any fixed point universal_fixed type type / divide any fixed point any fixed point universal_fixed type type Multiplication of operands of the same or of different fixed point types is exact and delivers a result of the anonymous predefined fixed point type universal_fixed whose delta is arbitrarily small. The result of any such multiplication must always be explicitly converted to some \vnumeric type\v310.. This ensures explicit control of the accuracy of the computation. The same considerations apply to division of a fixed point value by another fixed point value. No other operators are defined for the type universal_fixed. The exception \vNUMERIC_ERROR\v1101. is raised by integer division, rem, and mod if the right operand is zero. \uExamples:\n I : INTEGER := 1; J : INTEGER := 2; K : INTEGER := 3; X : REAL \udigits\n 6 := 1.0; -- see 3.5.7 Y : REAL \udigits\n 6 := 2.0; F : FRACTION \udelta\n 0.0001 := 0.1; -- see 3.5.9 G : FRACTION \udelta\n 0.0001 := 0.1; Expression Value Result Type I*J 2 same as I and J, that is, INTEGER K/J 1 same as K and J, that is, INTEGER K \umod\n J 1 same as K and J, that is, INTEGER X/Y 0.5 same as X and Y, that is, REAL F/2 0.05 same as F, that is, FRACTION 3*F 0.3 same as F, that is, FRACTION F*G 0.01 universal_fixed, conversion needed FRACTION(F*G) 0.01 FRACTION, as stated by the conversion REAL(J)*Y 4.0 REAL, the type of both operands after conversion of J \uNotes:\n For positive A and B, A/B is the quotient and A rem B is the remainder when A is divided by B. The following relations are satisfied by the rem operator: A \urem\n (-B) = A \urem\n B (-A) \urem\n B = -(A \urem\n B) For any integer K, the following identity holds: A \umod\n B = (A + K*B) \umod\n B The relations between integer division, remainder, and modulus are illustrated by the following table: A B A/B A \urem\n B A \umod\n B A B A/B A \urem\n B A \umod\n B 10 5 2 0 0 -10 5 -2 0 0 11 5 2 1 1 -11 5 -2 -1 4 12 5 2 2 2 -12 5 -2 -2 3 13 5 2 3 3 -13 5 -2 -3 2 14 5 2 4 4 -14 5 -2 -4 1 10 -5 -2 0 0 -10 -5 2 0 8 11 -5 -2 1 -4 -11 -5 2 -1 -1 12 -5 -2 2 -3 -12 -5 2 -2 -2 13 -5 -2 3 -2 -13 -5 2 -3 -3 14 -5 -2 4 -1 -14 -5 2 -4 -4 4.5.6 \uHighest Precedence Operators\n The highest precedence unary operator \uabs\n is predefined for any numeric type. The highest precedence unary operator not is predefined for any \vboolean type\v313. and any one-dimensional \varray type\v321. whose components have a boolean type. Operator Operation Operand type Result type \uabs\n absolute value any numeric type same numeric type \unot\n logical negation any boolean type same boolean type array of boolean components same array type The operator not that applies to a one-dimensional array of boolean components yields a one-dimensional boolean array with the same bounds; each component of the result is obtained by logical negation of the corresponding component of the operand (that is, the component that has the same \vindex\v321. value). The highest precedence exponentiating operator ** is predefined for each \vinteger type\v314. and for each \vfloating point type\v319.. In either case the right operand, called the exponent, is of the predefined type INTEGER. Operator Operation Left operand Right operand Result type type type ** exponentiation any integer type INTEGER same as left any floating point INTEGER same as left type Exponentiation with a positive exponent is equivalent to repeated \vmultiplication\v416. of the left operand by itself, as indicated by the exponent and from left to right. For an operand of a floating point type, the exponent can be negative, in which case the value is the reciprocal of the value with the positive exponent. Exponentiation by a zero exponent delivers the value one. Exponentiation of a value of a floating point type is approximate (see 4.5.7). Exponentiation of an integer raises the exception \vCONSTRAINT_ERROR\v1101. for a negative exponent. 4.5.7 \uAccuracy of Operations with Real Operands\n A real \vsubtype\v305. specifies a set of model numbers. Both the accuracy required from any basic or \vpredefined operation\v308. giving a real result, and the result of any predefined \vrelation\v410. between real operands are defined in terms of these \vmodel numbers\v316.. A model interval of a subtype is any interval whose bounds are model numbers of the subtype. The model interval associated with a value that belongs to a real subtype is the smallest model interval (of the subtype) that includes the value. (The model interval associated with a model number of a subtype consists of that number only.) For any \vbasic operation\v308. or predefined operator that yields a result of a real subtype, the required bounds on the result are given by a model interval defined as follows: - The result model interval is the smallest model interval (of the result subtype) that includes the minimum and the maximum of all the values obtained by applying the (exact) mathematical operation, when each operand is given any value of the model interval (of the operand subtype) defined for the operand. - The model interval of an operand that is itself the result of an operation, other than an implicit conversion, is the result model interval of this operation. - The model interval of an operand whose value is obtained by implicit conversion of a \vuniversal expression\v401. is the model interval associated with this value within the operand subtype. The result model interval is undefined if the absolute value of one of the above mathematical results exceeds the largest \vsafe number\v316. of the result type. Whenever the result model interval is undefined, it is highly desirable that the exception \vNUMERIC_ERROR\v1101. be raised if the implementation cannot produce an actual result that is in the \vrange\v311. of safe numbers. This is, however, not required by the language rules, in recognition of the fact that certain target machines do not permit easy detection of overflow situations. The value of the \vattribute\v405. \vMACHINE_OVERFLOWS\v1309. indicates whether the target machine raises the exception NUMERIC_ERROR in overflow situations (see 13.7.3). The safe numbers of a \vreal type\v316. are defined (see 3.5.6) as a superset of the model numbers, for which \verror bounds\v316. follow the same rules as for model numbers. Any definition given in this section in terms of model intervals can therefore be extended to safe intervals of safe numbers. A consequence of this extension is that an implementation is not allowed to raise the exception NUMERIC_ERROR when the result interval is a safe interval. For the result of \vexponentiation\v417., the model interval defining the bounds on the result is obtained by applying the above rules to the sequence of \vmultiplications\v416. defined by the exponent, and to the final division in the case of a negative exponent. For the result of a relation between two real operands, consider for each operand the model interval (of the operand subtype) defined for the operand; the result can be any value obtained by applying the mathematical comparison to values arbitrarily chosen in the corresponding operand model intervals. If either or both of the operand model intervals is undefined (and if neither of the operand evaluations raises an exception) then the result of the comparison is allowed to be any possible value (that is, either TRUE or FALSE). The result of a \vmembership test\v413. is defined in terms of comparisons of the operand value with the lower and upper bounds of the given range or type mark (the usual rules apply to these comparisons). Note: For a \vfloating point type\v319. the numbers 15.0, 3.0, and 5.0 are always model numbers. Hence X/Y where X equals 15.0 and Y equals 3.0 yields exactly 5.0 according to the above rules. In the general case, division does not yield model numbers and in consequence one cannot assume that (1.0/X)*X = 1.0. 4.6 \uType Conversions\n The evaluation of an explicit \vtype\v305. conversion evaluates the \vexpression\v410. given as the operand, and converts the resulting value to a specified target type. Explicit type conversions are allowed between closely related types as defined below. type_conversion ::= type_mark(expression) The target type of a type conversion is the \vbase type\v305. of the type mark. The type of the operand of a type conversion must be determinable independently of the context (in particular, independently of the target type). Furthermore, the operand of a type conversion is not allowed to be a literal null, an allocator, an aggregate, or a string literal; an expression enclosed by parentheses is allowed as the operand of a type conversion only if the expression alone is allowed. A conversion to a \vsubtype\v305. consists of a conversion to the target type followed by a check that the result of the conversion \vbelongs to the\v305. \vsubtype\v305.. A conversion of an operand of a given type to the type itself is allowed. The other allowed explicit type conversions correspond to the following three cases: (a) Numeric types The operand can be of any numeric type; the value of the operand is converted to the target type which must also be a numeric type. For conversions involving \vreal types\v316., the result is within the accuracy of the specified subtype (see 4.5.7). The conversion of a real value to an integer type rounds to the nearest integer; if the operand is halfway between two integers (within the accuracy of the real subtype) rounding may be either up or down. (b) \vDerived types\v309. The conversion is allowed if one of the target type and the operand type is derived from the other, directly or indirectly, or if there exists a third type from which both types are derived, directly or indirectly. (c) \vArray types\v321. The conversion is allowed if the operand type and the target type are array types that satisfy the following conditions: both types must have the same dimensionality; for each \vindex\v321. position the \vindex types\v321. must either be the same or be convertible to each other; the \vcomponent\v305. types must be the same; finally, if the component type is a type with discriminants or an access type, the component subtypes must be either both constrained or both unconstrained. If the type mark denotes an \vunconstrained array type\v321., then, for each index position, the bounds of the result are obtained by converting the bounds of the operand to the corresponding index type of the target type. If the \vtype mark\v307. denotes a \vconstrained array subtype\v321., then the bounds of the result are those imposed by the type mark. In either case, the value of each component of the result is that of the \vmatching component\v413. of the operand (see 4.5.2). In the case of conversions of numeric types and derived types, the exception \vCONSTRAINT_ERROR\v1101. is raised by the evaluation of a type conversion if the result of the conversion fails to satisfy a constraint imposed by the type mark. In the case of array types, a check is made that any constraint on the component subtype is the same for the operand array type as for the target array type. If the type mark denotes an unconstrained array type and if the operand is not a \vnull array\v322., then, for each index position, a check is made that the bounds of the result belong to the corresponding index subtype of the target type. If the type mark denotes a constrained array subtype, a check is made that for each component of the operand there is a matching component of the target subtype, and vice versa. The exception CONSTRAINT_ERROR is raised if any of these checks fails. If a conversion is allowed from one type to another, the reverse conversion is also allowed. This reverse conversion is used where an \vactual parameter\v607. of \vmode\v601. in out or out has the form of a type conversion of a (\vvariable\v303.) \vname\v401. as explained in section 6.4.1. Apart from the explicit type conversions, the only allowed form of type conversion is the implicit conversion of a value of the type \vuniversal_integer\v314. or \vuniversal_real\v316. into another \vnumeric type\v310.. An implicit conversion of an operand of type universal_integer to another integer type, or of an operand of type universal_real to another real type, can only be applied if the operand is either a \vnumeric literal\v204., a \vnamed number\v302., or an \vattribute\v405.; such an operand is called a convertible universal operand in this section. An implicit conversion of a convertible universal operand is applied if and only if the innermost complete context (see 8.7) determines a unique (numeric) target type for the implicit conversion, and there is no legal interpretation of this context without this conversion. \uNotes:\n The rules for implicit conversions imply that no implicit conversion is ever applied to the operand of an explicit type conversion. Similarly, implicit conversions are not applied if both operands of a predefined relational operator are convertible universal operands. The language allows implicit subtype conversions in the case of array types (see 5.2.1). An explicit type conversion can have the effect of a change of \vrepresentation\v1301. (in particular see 13.6). Explicit conversions are also used for actual parameters (see 6.4). Examples of numeric type conversion: REAL(2*J) -- value is converted to \vfloating point\v317. INTEGER(1.6) -- value is 2 INTEGER(-0.4) -- value is 0 Example of conversion between derived types: type A_FORM is new B_FORM; X : A_FORM; Y : B_FORM; X := A_FORM(Y); Y := B_FORM(X); -- the reverse conversion Examples of conversions between array types: \utype\n SEQUENCE \uis array\n (INTEGER \urange\n <>) \uof\n INTEGER; \usubtype\n DOZEN \uis\n SEQUENCE(1 .. 12); LEDGER : \uarray\n(1 .. 100) \uof\n INTEGER; SEQUENCE(LEDGER) -- bounds are those of LEDGER SEQUENCE(LEDGER(31 .. 42)) -- bounds are 31 and 42 DOZEN(LEDGER(31 .. 42)) -- bounds are those of DOZEN Examples of implicit conversions: X : INTEGER := 2; X + 1 + 2 -- implicit conversion of each integer literal 1 + 2 + X -- implicit conversion of each integer literal X + (1 + 2) -- implicit conversion of each integer literal 2 = (1 + 1) -- no implicit conversion: the type is uni- versal_integer A'LENGTH = B'LENGTH -- no implicit conversion: the type is uni- versal_integer C : \uconstant\n := 3 + 2; -- no implicit conversion: the type is uni- versal_integer X = 3 \uand\n 1 = 2 -- implicit conversion of 3, but not of 1 and 2 4.7 \uQualified Expressions\n A qualified \vexpression\v410. is used to state explicitly the \vtype\v305., and possibly the \vsubtype\v305., of an operand that is the given expression or \vaggregate\v407.. qualified_expression ::= type_mark'(expression) | type_mark'aggregate The operand must have the same type as the \vbase type\v305. of the \vtype mark\v307.. The value of a qualified expression is the value of the operand. The evaluation of a qualified expression evaluates the operand and checks that its value belongs to the subtype denoted by the type mark. The exception \vCONSTRAINT_ERROR\v1101. is raised if this check fails. \uExamples:\n \utype\n MASK \uis\n (FIX, DEC, EXP, SIGNIF); \utype\n CODE \uis\n (FIX, CLA, DEC, TNZ, SUB); PRINT (MASK'(DEC)); -- DEC is of type MASK PRINT (CODE'(DEC)); -- DEC is of type CODE \ufor\n J \uin\n CODE'(FIX) .. CODE'(DEC) \uloop\n ... -- qualification needed for either FIX or DEC \ufor\n J \uin\n CODE \urange\n FIX .. DEC \uloop\n ... -- qualification unnecessary \ufor\n J \uin\n CODE'(FIX) .. DEC \uloop\n ... -- qualification unnecessary for DEC DOZEN'(1 | 3 | 5 | 7 => 2, \uothers\n => 0) -- see 4.6 \uNotes:\n Whenever the type of an \venumeration literal\v311. or aggregate is not known from the context, a qualified expression can be used to state the type explicitly. For example, an overloaded enumeration literal must be qualified in the following cases: when given as a parameter in a \vsubprogram\v600. call to an overloaded subprogram that cannot otherwise be identified on the basis of remaining parameter or result types, in a relational expression where both operands are overloaded enumeration literals, or in an \varray\v321. or \vloop parameter\v506. range where both bounds are overloaded enumeration literals. Explicit qualification is also used to specify which one of a set of overloaded parameterless \vfunctions\v609. is meant, or to constrain a value to a given subtype. 4.8 \uAllocators\n The evaluation of an allocator creates an \vobject\v303. and yields an \vaccess value\v330. that \vdesignates\v330. the object. allocator ::= \unew\n \vsubtype_indication\v307. | \unew\n \vqualified_expression\v420. The \vtype\v305. of the object created by an allocator is the base type of the type mark given in either the subtype indication or the qualified expression. For an allocator with a qualified expression, this expression defines the \vinitial value\v303. of the created object. The type of the access value returned by an allocator must be determinable solely from the context, but using the fact that the value returned is of an \vaccess type\v330. having the named designated type. The only allowed forms of \vconstraint\v305. in the subtype indication of an allocator are index and \vdiscriminant constraints\327.. If an allocator includes a subtype indication and if the type of the object created is an \varray type\v321. or a \vtype with discriminants\v305. that do not have default expressions, then the subtype indication must either denote a constrained subtype, or include an explicit index or discriminant constraint. If the type of the created object is an array type or a type with discriminants, then the created object is always constrained. If the allocator includes a subtype indication, the created object is constrained either by the subtype or by the default discriminant values. If the allocator includes a qualified expression, the created object is constrained by the bounds or discriminants of the initial value. For other types, the subtype of the created object is the subtype defined by the subtype indication of the \vaccess type definition\v330.. For the evaluation of an allocator, the \velaboration\v333. of the subtype indication or the \vevaluation of the qualified expression\v420. is performed first. The new object is then created. Initializations are then performed as for a declared object (see 3.2.1); the \vinitialization\v303. is considered explicit in the case of a qualified expression; any initializations are implicit in the case of a subtype indication. Finally, an access value that designates the created object is returned. An implementation must guarantee that any object created by the evaluation of an allocator remains allocated for as long as this object or one of its \vsubcomponents\v305. is accessible directly or indirectly, that is, as long as it can be denoted by some name. Moreover, if an object or one of its subcomponents belongs to a \vtask type\v902., it is considered to be accessible as long as the task is not terminated. An implementation may (but need not) reclaim the storage occupied by an object created by an allocator, once this object has become inaccessible. When an application needs closer control over storage allocation for objects designated by values of an access type, such control may be achieved by one or more of the following means: (a) The total amount of storage available for the \vcollection\v330. of objects of an access type can be set by means of a \vlength clause\v1302. (see 13.2). (b) The \vpragma\v210. CONTROLLED informs the implementation that automatic storage reclamation must not be performed for objects designated by values of the access type, except upon leaving the innermost \vblock\v507. statement, \vsubprogram body\v603., or \vtask body\v901. that encloses the access type declaration, or after leaving the \vmain program\v1001.. \upragma\n CONTROLLED (access_type_simple_name); A pragma CONTROLLED for a given access type is allowed at the same places as a \vrepresentation clause\v1301. for the type (see 13.1). This pragma is not allowed for a \vderived type\v309.. (c) The explicit deallocation of the object designated by an access value can be achieved by calling a \vprocedure\v600. obtained by \vinstantiation\v1206. of the predefined \vgeneric library procedure\v1201. UNCHECKED_DEALLOCATION (see 13.10.1). The exception \vSTORAGE_ERROR\v1101. is raised by an allocator if there is not enough storage. Note also that the exception CONSTRAINT_ERROR can be raised by the evaluation of the qualified expression, by the elaboration of the subtype indication, or by the initialization. Examples (for access types declared in section 3.8): \unew\n CELL'(0, \unull\n, \unull\n) -- initialized explicitly \unew\n CELL'(VALUE => 0, SUCC => \unull\n, PRED => \unull\n) -- initialized explicitly \unew\n CELL -- not initialized \unew\n MATRIX(1 .. 10, 1 .. 20) -- the bounds only are given \unew\n MATRIX'(1 .. 10 => (1 .. 20 => 0.0)) -- initialized explicitly \unew\n BUFFER(100) -- the discriminant only is given \unew\n BUFFER'(SIZE => 80, POS => 0, VALUE => (1 .. 80 => 'A')) -- initialized explicitly 4.9 \uStatic Expressions and Static Subtypes\n Certain \vexpressions\v410. of a \vscalar type\v310. are said to be static. Similarly, certain \vdiscrete ranges\v321. are said to be static, and the type marks of certain scalar \vsubtypes\v305. are said to denote static subtypes. An expression of a scalar type is said to be static if and only if every primary is one of those listed in (a) through (h) below, every operator denotes a \vpredefined operator\v411., and the evaluation of the expression delivers a value (that is, it does not raise an \vexception\v1100.): (a) An \venumeration literal\v311. (including a \vcharacter literal\v207.). (b) A \vnumeric literal\v204.. (c) A \vnamed number\v302.. (d) A \vconstant\v303. explicitly declared by a \vconstant declaration\v303. with a static subtype, and \vinitialized\v303. with a static expression. (e) A \vfunction\v609. call whose function name is an operator symbol that denotes a predefined operator, including a function name that is an expanded name; each \vactual parameter\v607. must also be a static expression. (f) A language-defined \vattribute\v405. of a static subtype; for an attribute that is a function, the actual parameter must also be a static expression. (g) A \vqualified expression\v420. whose \vtype mark\v307. denotes a static subtype and whose operand is a static expression. (h) A static expression enclosed in parentheses. A static range is a range whose bounds are static expressions. A static range constraint is a \vrange constraint\v310. whose range is static. A static subtype is either a scalar \vbase type\v305., other than a \vgeneric formal type\v1203.; or a scalar subtype formed by imposing on a static subtype either a static range constraint, or a floating or fixed point constraint whose range constraint, if any, is static. A static discrete range is either a static subtype or a static range. A static index constraint is an index constraint for which each index subtype of the corresponding array type is static, and in which each discrete range is static. A static discriminant constraint is a discriminant constraint for which the subtype of each discriminant is static, and in which each expression is static. \uNotes:\n The accuracy of the evaluation of a static expression having a real type is defined by the rules given in section 4.5.7. If the result is not a \vmodel\v316. \vnumber\v316. (or a \vsafe number\v316.) of the type, the value obtained by this evaluation at compilation time need not be the same as the value that would be obtained by an evaluation at run time. Array attributes are not static: in particular, the RANGE attribute is not static. 4.10 \uUniversal Expressions\n A universal_expression is either an expression that delivers a result of type \vuniversal_integer\v314. or one that delivers a result of type universal_real. The same \voperations are predefined\v308. for the type universal_integer as for any \vinteger type\v314.. The same operations are predefined for the type universal_real as for any \vfloating point type\v319.. In addition, these operations include the following multiplication and division operators: Operator Operation Left operand Right operand Result type type type * multiply universal_real universal_integer universal_real universal_integer universal_real universal_real / divide universal_real universal_integer universal_real The accuracy of the \vevaluation of a universal expression\v411. of type universal_real is at least as good as that of the most accurate predefined floating point type supported by the implementation, apart from universal_real itself. Furthermore, if a universal expression is a static expression, then the evaluation must be exact. For the evaluation of an operation of a nonstatic universal expression, an implementation is allowed to raise the exception NUMERIC_ERROR only if the result of the operation is a real value whose absolute value exceeds the largest \vsafe number\v316. of the most accurate predefined floating point type (excluding universal_real), or an integer value greater than \vSYSTEM.MAX_INT\v1308. or less than \vSYSTEM.MIN_INT\v1308.. Note: It is a consequence of the above rules that the type of a universal expression is universal_integer if every \vprimary\v410. contained in the expression is of this type (excluding \vactual parameters\v607. of \vattributes\v405. that are \vfunctions\v609., and excluding right operands of exponentiation operators) and that otherwise the type is universal_real. \uExamples:\n 1 + 1 -- 2 \uabs\n(-10)*3 -- 30 KILO : \uconstant\n := 1000; MEGA : \uconstant\n := KILO*KILO; -- 1_000_000 LONG : \uconstant\n := FLOAT'DIGITS*2; HALF_PI : \uconstant\n := PI/2; -- see 3.2.2 DEG_TO_RAD : \uconstant\n := HALF_PI/90; RAD_TO_DEG : \uconstant\n := 1.0/DEG_TO_RAD; -- equivalent to 1.0/((3.14159_26536/2)/90) 5. \uStatements\n A statement defines an action to be performed; the process by which a statement achieves its action is called execution of the statement. This chapter describes the general rules applicable to all statements. Some specific statements are discussed in later chapters. \vProcedure call\v606. \vstatements\v606. are described in Chapter 6 on subprograms. \vEntry call\v905., \vdelay\v906., \vaccept\v905., \vselect\v907., and \vabort statements\v913. are described in Chapter 9 on tasks. \vRaise statements\v1103. are described in Chapter 11 on exceptions, and \vcode\v1312. \vstatements\v1312. in Chapter 13. The remaining forms of statements are presented in this chapter. More details: 5.1 \vSimple and Compound Statements - Sequences of Statements\v501. 5.2 \vAssignment Statement\v502. 5.3 \vIf Statements\v504. 5.4 \vCase Statements\v505. 5.5 \vLoop Statements\v506. 5.6 \vBlock Statements\v507. 5.7 \vExit Statements\v508. 5.8 \vReturn Statements\v509. 5.9 \vGoto Statements\v510. 5.1 \uSimple and Compound Statements - Sequences of Statements\n A statement is either simple or compound. A simple statement encloses no other statement. A compound statement can enclose simple statements and other compound statements. sequence_of_statements ::= statement {statement} statement ::= {label} simple_statement | {label} compound_statement simple_statement ::= null_statement | \vassignment_statement\v502. | \vprocedure_call_statement\v606. | \vexit_statement\v508. | \vreturn_statement\v509. | \vgoto_statement\v510. | \ventry_call_statement\v905. | \vdelay_statement\v906. | \vabort_statement\v913. | \vraise_statement\v1103. | \vcode_statement\v1312. compound_statement ::= \vif_statement\v504. | \vcase_statement\v505. | \vloop_statement\v506. | \vblock_statement\v507. | \vaccept_statement\v905. | \vselect_statement\v907. label ::= <> null_statement ::= \unull\n; A statement is said to be labeled by the label name of any label of the statement. A label name, and similarly a loop or \vblock name\v507., is implicitly declared at the end of the declarative part of the innermost block statement, \vsubprogram body\v603., \vpackage body\v701., \vtask body\v901., or \vgeneric body\v1201. that encloses the labeled statement, the named loop statement, or the named block statement, as the case may be. For a block statement without a declarative part, an implicit \vdeclarative part\v333. (and preceding declare) is assumed. The \vimplicit declarations\v301. for different label names, \vloop names\v506., and block names occur in the same order as the beginnings of the corresponding labeled statements, loop statements, and block statements. Distinct \videntifiers\v203. must be used for all label, loop, and block names that are implicitly declared within the body of a program unit, including within block statements enclosed by this body, but excluding within other enclosed program units (a program unit is either a \vsubprogram\v600., a \vpackage\v700., a \vtask\v901. \vunit\v901., or a \vgeneric unit\v1200.). Execution of a null statement has no other effect than to pass to the next action. The execution of a sequence of statements consists of the execution of the individual statements in succession until the sequence is completed, or a transfer of control takes place. A transfer of control is caused either by the execution of an exit, return, or goto statement; by the selection of a \vterminate alternative\v908.; by the \vraising of an exception\v1100.; or (indirectly) by the execution of an abort statement. Examples of labeled statements: <> <> <> <> \unull\n; <> X := 1; Note: The \vscope\v802. of a declaration starts at the place of the \vdeclaration\v301. itself (see 8.2). In the case of a label, loop, or block name, it follows from this rule that the scope of the implicit declaration starts before the first explicit occurrence of the corresponding name, since this occurrence is either in a statement label, a loop statement, a block statement, or a goto statement. An implicit declaration in a block statement may hide a declaration given in an outer \vprogram unit\v600. or block statement (according to the usual rules of \vhiding\v803. explained in section 8.3). 5.2 \uAssignment Statement\n An assignment statement replaces the current value of a \vvariable\v303. with a new value specified by an \vexpression\v410.. The named variable and the right-hand side expression must be of the same \vtype\v305.; this type must not be a limited type. assignment_statement ::= variable_name := expression; For the execution of an assignment statement, the variable \vname\v401. and the expression are first evaluated, in some order that is not defined by the language. A check is then made that the value of the expression belongs to the \vsubtype\v305. of the variable, except in the case of a variable that is an \varray\v321. (the assignment then involves a \vsubtype conversion\v419. as described in section 5.2.1). Finally, the value of the expression becomes the new value of the variable. The \vexception CONSTRAINT_ERROR\v1101. is raised if the above-mentioned subtype check fails; in such a case the current value of the variable is left unchanged. If the variable is a \vsubcomponent\v305. that depends on \vdiscriminants\v326. of an unconstrained record variable, then the execution of the assignment is \verroneous\v108. if the value of any of these discriminants is changed by this execution. \uExamples:\n VALUE := MAX_VALUE - 1; SHADE := BLUE; NEXT_FRAME(F)(M, N) := 2.5; -- see 4.1.1 U := DOT_PRODUCT(V, W); -- see 6.5 WRITER := (STATUS => OPEN, UNIT => PRINTER, LINE_COUNT => 60); -- see 3.7.3 NEXT_CAR.\uall\n := (72074, \unull\n); -- see 3.8.1 Examples of constraint checks: I, J : INTEGER \urange\n 1 .. 10; K : INTEGER \urange\n 1 .. 20; ... I := J; -- identical ranges K := J; -- compatible ranges J := K; -- will raise the exception CONSTRAINT_ERROR if K > 10 \uNotes:\n The values of the discriminants of an \vobject\v302. designated by an access value cannot be changed (not even by assigning a complete value to the object itself) since such objects, created by \vallocators\v421., are always constrained (see 4.8); however, subcomponents of such objects may be unconstrained. If the right-hand side expression is either a \vnumeric literal\v204. or named number, or an attribute that yields a result of \vtype universal_integer\v314. or \vuniversal_real\v316., then an \vimplicit type conversion\v419. is performed, as described in section 4.6. The determination of the type of the variable of an assignment statement may require consideration of the expression if the variable name can be interpreted as the name of a variable \vdesignated\v330. by the access value returned by a \vfunction call\v606., and similarly, as a \vcomponent\v321. or \vslice\v403. of such a variable (see section 8.7 for the context of \voverload\v610. resolution). More details: 5.2.1 \vArray Assigments\v503. 5.2.1 \uArray Assignments\n If the \vvariable\v303. of an \vassignment\v502. statement is an \varray\v321. variable (including a \vslice\v403. variable), the value of the expression is implicitly converted to the subtype of the array variable; the result of this \vsubtype conversion\v419. becomes the new value of the array variable. This means that the new value of each component of the array variable is specified by the \vmatching component in the array\v413. value obtained by evaluation of the expression (see 4.5.2 for the definition of matching components). The subtype conversion checks that for each component of the array variable there is a matching component in the array value, and vice versa. The \vexception CONSTRAINT_ERROR\v1101. is raised if this check fails; in such a case the value of each component of the array variable is left unchanged. \uExamples:\n A : STRING(1 .. 31); B : STRING(3 .. 33); ... A := B; -- same number of components A(1 .. 9) := "tar sauce"; A(4 .. 12) := A(1 .. 9); -- A(1 .. 12) = "tartar sauce" \uNotes:\n Array assignment is defined even in the case of overlapping slices, because the expression on the right-hand side is evaluated before performing any component assignment. In the above example, an implementation yielding A(1 .. 12) = "tartartartar" would be incorrect. The implicit subtype conversion described above for assignment to an array variable is performed only for the value of the right-hand side expression as a whole; it is not performed for subcomponents that are array values. 5.3 \uIf Statements\n An if statement selects for execution one or none of the enclosed \vsequences\v501. \vof statements\v501., depending on the (truth) value of one or more corresponding conditions. if_statement ::= \uif\n condition \uthen\n sequence_of_statements {\uelsif\n condition \uthen\n sequence_of_statements} [\uelse\n sequence_of_statements] \uend if\n; condition ::= boolean_expression An \vexpression\v410. specifying a condition must be of a \vboolean type\v313.. For the execution of an if statement, the condition specified after if, and any conditions specified after elsif, are evaluated in succession (treating a final else as elsif TRUE then), until one evaluates to TRUE or all conditions are evaluated and yield FALSE. If one condition evaluates to TRUE, then the corresponding sequence of statements is executed; otherwise none of the sequences of statements is executed. \uExamples:\n \uif\n MONTH = DECEMBER \uand\n DAY = 31 \uthen\n MONTH := JANUARY; DAY := 1; YEAR := YEAR + 1; \uend if\n; \uif\n LINE_TOO_SHORT \uthen\n \uraise\n LAYOUT_ERROR; \uelsif\n LINE_FULL \uthen\n NEW_LINE; PUT(ITEM); \uelse\n PUT(ITEM); \uend if\n; \uif\n MY_CAR.OWNER.VEHICLE /= MY_CAR \uthen\n -- see 3.8 REPORT ("Incorrect data"); \uend if\n; 5.4 \u Case Statements\n A case statement selects for execution one of a number of alternative \vsequences of statements\v501.; the chosen alternative is defined by the value of an \vexpression\v410.. case_statement ::= \ucase\n expression \uis\n case_statement_alternative {case_statement_alternative} \uend case\n; case_statement_alternative ::= \uwhen\n \vchoice\v328. {| choice } => sequence_of_statements The expression must be of a \vdiscrete type\v310. which must be determinable independently of the context in which the expression occurs, but using the fact that the expression must be of a discrete \vtype\v305.. Moreover, the type of this expression must not be a \vgeneric formal type\v1201.. Each choice in a case statement alternative must be of the same type as the expression; the list of choices specifies for which values of the expression the alternative is chosen. If the expression is the \vname\v401. of an \vobject\v303. whose \vsubtype\v305. is static, then each value of this subtype must be represented once and only once in the set of choices of the case statement, and no other value is allowed; this rule is likewise applied if the expression is a \vqualified expression\v420. or \vtype conversion\v419. whose \vtype mark\v307. denotes a \vstatic subtype\v422.. Otherwise, for other forms of expression, each value of the (\vbase\v305.) type of the expression must be represented once and only once in the set of choices, and no other value is allowed. The simple expressions and discrete ranges given as choices in a case statement must be static. A choice defined by a discrete range stands for all values in the corresponding range (none if a null range). The choice others is only allowed for the last alternative and as its only choice; it stands for all values (possibly none) not given in the choices of previous alternatives. A component simple name is not allowed as a choice of a case statement alternative. The execution of a case statement consists of the evaluation of the expression followed by the execution of the chosen sequence of statements. \uExamples:\n \ucase\n SENSOR \uis\n \uwhen\n ELEVATION => RECORD_ELEVATION(SENSOR_VALUE); \uwhen\n AZIMUTH => RECORD_AZIMUTH (SENSOR_VALUE); \uwhen\n DISTANCE => RECORD_DISTANCE (SENSOR_VALUE); \uwhen\n others => \unull\n; \uend case\n; \ucase\n TODAY \uis\n \uwhen\n MON => COMPUTE_INITIAL_BALANCE; \uwhen\n FRI => COMPUTE_CLOSING_BALANCE; \uwhen\n TUE .. THU => GENERATE_REPORT(TODAY); \uwhen\n SAT .. SUN => \unull\n; \uend case\n; \ucase\n BIN_NUMBER(COUNT) \uis\n \uwhen\n 1 => UPDATE_BIN(1); \uwhen\n 2 => UPDATE_BIN(2); \uwhen\n 3 | 4 => EMPTY_BIN(1); EMPTY_BIN(2); \uwhen others\n => raise ERROR; \uend case\n; \uNotes:\n The execution of a case statement chooses one and only one alternative, since the choices are exhaustive and mutually exclusive. Qualification of the expression of a case statement by a static subtype can often be used to limit the number of choices that need be given explicitly. An others choice is required in a case statement if the type of the expression is the type universal_integer (for example, if the expression is an integer literal), since this is the only way to cover all values of the type universal_integer. 5.5 \uLoop Statements\n A loop statement includes a \vsequence of statements\v501. that is to be executed repeatedly, zero or more times. loop_statement ::= [loop_simple_name:] [iteration_scheme] \uloop\n sequence_of_statements \uend loop\n [loop_simple_name]; iteration_scheme ::= \uwhile\n condition | \ufor\n loop_parameter_specification loop_parameter_specification ::= identifier \uin\n [\ureverse\n] discrete_range If a loop statement has a loop \vsimple name\v401., this simple name must be given both at the beginning and at the end. A loop statement without an iteration scheme specifies repeated execution of the sequence of statements. Execution of the loop statement is complete when the loop is left as a consequence of the execution of an \vexit\v508. \vstatement\v508., or as a consequence of some other transfer of control (see 5.1). For a loop statement with a while iteration scheme, the \vcondition\v504. is evaluated before each execution of the sequence of statements; if the value of the condition is \vTRUE\v313., the sequence of statements is executed, if \vFALSE\v313. the execution of the loop statement is complete. For a loop statement with a for iteration scheme, the loop parameter specification is the \vdeclaration\v301. of the loop parameter with the given \videntifier\v203.. The loop parameter is an \vobject\v303. whose type is the \vbase type\v305. of the \vdiscrete range\v322. (see 3.6.1). Within the sequence of statements, the loop parameter is a \vconstant\v303.. Hence a loop parameter is not allowed as the (left-hand side) variable of an \vassignment statement\v502.. Similarly the loop parameter must not be given as an out or in out parameter of a \vprocedure\v606. or \ventry call statement\v905., or as an in out parameter of a \vgeneric instantiation\v1206.. For the execution of a loop statement with a for iteration scheme, the loop parameter specification is first elaborated. This \velaboration\v301. creates the loop parameter and evaluates the discrete range. If the discrete range is a \vnull range\v310., the execution of the loop statement is complete. Otherwise, the sequence of statements is executed once for each value of the discrete range (subject to the loop not being left as a consequence of the execution of an exit statement or as a consequence of some other transfer of control). Prior to each such iteration, the corresponding value of the discrete range is assigned to the loop parameter. These values are assigned in increasing order unless the \vreserved word\v211. reverse is present, in which case the values are assigned in decreasing order. Example of a loop statement without an iteration scheme: \uloop\n GET(CURRENT_CHARACTER); \uexit when\n CURRENT_CHARACTER = '*'; \uend loop\n; Example of a loop statement with a while iteration scheme: \uwhile\n BID(N).PRICE < CUT_OFF.PRICE \uloop\n RECORD_BID(BID(N).PRICE); N := N + 1; \uend loop\n; Example of a loop statement with a for iteration scheme: \ufor\n J \uin\n BUFFER'RANGE \uloop\n -- legal even with a null range \uif\n BUFFER(J) /= SPACE \uthen\n PUT(BUFFER(J)); \uend if\n; \uend loop\n; Example of a loop statement with a loop simple name: SUMMATION: \uwhile\n NEXT /= HEAD \uloop\n -- see 3.8 SUM := SUM + NEXT.VALUE; NEXT := NEXT.SUCC; \uend loop\n SUMMATION; \uNotes:\n The \vscope\v802. of a loop parameter extends from the loop parameter specification to the end of the loop statement, and the \vvisibility\v803. rules are such that a loop parameter is only visible within the sequence of statements of the loop. The discrete range of a for loop is evaluated just once. Use of the reserved word reverse does not alter the discrete range, so that the following iteration schemes are not equivalent; the first has a null range. \ufor\n J \uin reverse\n 1 .. 0 \ufor\n J \uin\n 0 .. 1 Loop names are also used in exit statements, and in \vexpanded names\v404. (in a \vprefix\v401. of the loop parameter). 5.6 \uBlock Statements\n A block statement encloses a \vsequence of statements\v501. optionally preceded by a \vdeclarative part\v333. and optionally followed by \vexception handlers\v1102.. block_statement ::= [block_simple_name:] [\udeclare\n declarative_part] \ubegin\n sequence_of_statements [\uexception\n exception_handler {exception_handler}] \uend\n [block_simple_name]; If a block statement has a block \vsimple name\v401., this simple name must be given both at the beginning and at the end. The execution of a block statement consists of the elaboration of its declarative part (if any) followed by the execution of the sequence of statements. If the block statement has exception handlers, these service corresponding exceptions that are raised during the execution of the sequence of statements (see 11.2). Example: SWAP: \udeclare\n TEMP : INTEGER; \ubegin\n TEMP := V; V := U; U := TEMP; \uend\n SWAP; \uNotes:\n If \vtask objects\v902. are declared within a block statement whose execution is completed, the block statement is not left until all its \vdependent tasks\v904. are terminated (see 9.4). This rule applies also to a completion caused by an \vexit\v508., \vreturn\v509., or \vgoto statement\v510.; or by the \vraising of an exception\v1100.. Within a block statement, the block name can be used in \vexpanded names\v404. denoting local entities such as SWAP.TEMP in the above example (see 4.1.3 (f)). 5.7 \uExit Statements\n An exit statement is used to complete the execution of an enclosing \vloop\v506. \vstatement\v506. (called the loop in what follows); the completion is conditional if the exit statement includes a \vcondition\v504.. exit_statement ::= \uexit\n [loop_name] [\uwhen\n condition]; An exit statement with a \vloop name\v506. is only allowed within the named loop, and applies to that loop; an exit statement without a loop name is only allowed within a loop, and applies to the innermost enclosing loop (whether named or not). Furthermore, an exit statement that applies to a given loop must not appear within a \vsubprogram body\v603., \vpackage body\v701., task body, \vgeneric\v1201. \vbody\v1201., or \vaccept statement\v905., if this construct is itself enclosed by the given loop. For the execution of an exit statement, the condition, if present, is first evaluated. Exit from the loop then takes place if the value is \vTRUE\v313. or if there is no condition. \uExamples:\n \ufor\n N \uin\n 1 .. MAX_NUM_ITEMS \uloop\n GET_NEW_ITEM(NEW_ITEM); MERGE_ITEM(NEW_ITEM, STORAGE_FILE); \uexit when\n NEW_ITEM = TERMINAL_ITEM; \uend loop\n; MAIN_CYCLE: \uloop\n -- initial statements \uexit\n MAIN_CYCLE \uwhen\n FOUND; -- final statements \uend loop\n MAIN_CYCLE; Note: Several nested loops can be exited by an exit statement that names the outer loop. 5.8 \uReturn Statements\n A return statement is used to complete the execution of the innermost enclosing function, procedure, or \vaccept statement\v905.. return_statement ::= \ureturn\n [expression]; A return statement is only allowed within the body of a \vsubprogram\v603. or generic subprogram, or within an accept statement, and applies to the innermost (enclosing) such construct; a return statement is not allowed within the body of a \vtask unit\v901., \vpackage\v701., or generic package enclosed by this construct (on the other hand, it is allowed within a compound statement enclosed by this construct and, in particular, in a \vblock\v507. \vstatement\v507.). A return statement for an accept statement or for the body of a \vprocedure\v603. or generic procedure must not include an \vexpression\v410.. A return statement for the body of a \vfunction\v603. or generic function must include an expression. The value of the expression defines the result returned by the function. The type of this expression must be the base type of the \vtype mark\v307. given after the \vreserved word\v211. return in the specification of the function or generic function (this type mark defines the \vresult subtype\v601.). For the execution of a return statement, the expression (if any) is first evaluated and a check is made that the value belongs to the result \vsubtype\v305.. The execution of the return statement is thereby completed if the check succeeds; so also is the execution of the subprogram or of the accept statement. The \vexception CONSTRAINT_ERROR\v1101. is raised at the place of the return statement if the check fails. \uExamples:\n \ureturn\n; -- in a procedure \ureturn\n KEY_VALUE(LAST_INDEX); -- in a function Note: If the expression is either a \vnumeric literal\v204. or \vnamed number\v302., or an \vattribute\v1500. that yields a result of \vtype universal_integer\v314. or \vuniversal_real\v316., then an \vimplicit conversion\v419. of the result is performed as described in section 4.6. 5.9 \uGoto Statements\n A goto statement specifies an explicit \vtransfer of control\v501. from this \vstatement\v501. to a target statement named by a \vlabel\v501.. goto_statement ::= \ugoto\n label_name; The innermost \vsequence of statements\v501. that encloses the target statement must also enclose the goto statement (note that the goto statement can be a statement of an inner sequence). Furthermore, if a goto statement is enclosed by an \vaccept statement\v905. or the body of a \vprogram unit\v600., then the target statement must not be outside this enclosing construct; conversely, it follows from the previous rule that if the target statement is enclosed by such a construct, then the goto statement cannot be outside. The execution of a goto statement transfers control to the named target statement. Note: The above rules allow transfer of control to a statement of an enclosing sequence of statements but not the reverse. Similarly, they prohibit transfers of control such as between alternatives of a \vcase statement\v505., \vif\v504. \vstatement\v504., or \vselect statement\v907.; between \vexception handlers\v1102.; or from an exception handler of a \vframe\v1102. back to the sequence of statements of this frame. Example: <> \uif\n A(I) < ELEMENT \uthen\n \uif\n LEFT(I) /= 0 \uthen\n I := LEFT(I); \ugoto\n COMPARE; \uend if\n; -- some statements \uend if\n; 6. \uSubprograms\n Subprograms are one of the four forms of program unit, of which programs can be composed. The other forms are \vpackages\v700., \vtask units\v900., and \vgeneric\v1200. \vunits\v1200.. A subprogram is a program unit whose execution is invoked by a \vsubprogram\v606. \vcall\v606.. There are two forms of subprogram: \vprocedures\v601. and \vfunctions\v609.. A \vprocedure call\v606. is a statement; a \vfunction call\v606. is an expression and returns a value. The definition of a subprogram can be given in two parts: a \vsubprogram declaration\v601. defining its calling conventions, and a \vsubprogram\v603. \vbody\v603. defining its execution. More details: 6.1 \vSubprogram Declarations\v601. 6.2 \vFormal Parameter Modes\v602. 6.3 \vSubprogram Bodies\v603. 6.4 \vSubprogram Calls\v606. 6.5 \vFunction Subprograms\v609. 6.6 \vParameter and Result Type Profile - Overloading of Subprograms\v610. 6.7 \vOverloading of Operators\v611. 6.1 \uSubprogram Declarations\n A subprogram \vdeclaration\v301. declares a \vprocedure\v600. or a \vfunction\v609., as indicated by the initial reserved word. subprogram_declaration ::= subprogram_specification; subprogram_specification ::= procedure identifier [formal_part] | function designator [formal_part] \ureturn\n \vtype_mark\v307. designator ::= identifier | operator_symbol operator_symbol ::= \vstring_literal\v208. formal_part ::= (parameter_specification {; parameter_specification}) parameter_specification ::= \videntifier_list\v302. : mode type_mark [:= expression] mode ::= [\uin\n] | \uin out\n | \uout\n The specification of a procedure specifies its \videntifier\v203. and its \vformal\v602. \vparameters\v602. (if any). The specification of a function specifies its designator, its formal parameters (if any) and the subtype of the returned value (the result subtype). A designator that is an \voperator\v411. symbol is used for the \voverloading\v610. of an operator. The sequence of characters represented by an operator symbol must be an operator belonging to one of the six classes of overloadable operators defined in section 4.5 (extra spaces are not allowed and the case of letters is not significant). A parameter specification with several identifiers is equivalent to a sequence of single parameter specifications, as explained in section 3.2. Each single parameter specification declares a formal parameter. If no \vmode\v602. is explicitly given, the mode in is assumed. If a parameter specification ends with an \vexpression\v410., the expression is the default expression of the formal parameter. A default expression is only allowed in a parameter specification if the mode is in (whether this mode is indicated explicitly or implicitly). The type of a default expression must be that of the corresponding formal parameter. The use of a \vname\v401. that denotes a formal parameter is not allowed in default expressions of a formal part if the specification of the parameter is itself given in this formal part. The \velaboration\v333. of a subprogram declaration elaborates the corresponding formal part. The \velaboration of a formal part has no other effect\v333.. Examples of subprogram declarations: \uprocedure\n TRAVERSE_TREE; \uprocedure\n INCREMENT(X : \uin out\n INTEGER); \uprocedure\n RIGHT_INDENT(MARGIN : \uout\n LINE_SIZE); -- see 3.5.4 \uprocedure\n SWITCH(FROM, TO : \uin out\n LINK); -- see 3.8.1 \ufunction\n RANDOM \ureturn\n PROBABILITY; -- see 3.5.7 \ufunction\n MIN_CELL(X : LINK) \ureturn\n CELL; -- see 3.8.1 \ufunction\n NEXT_FRAME(K : POSITIVE) \ureturn\n FRAME; -- see 3.8 \ufunction\n DOT_PRODUCT(LEFT,RIGHT: VECTOR) \ureturn\n REAL; -- see 3.6 \ufunction\n "*"(LEFT,RIGHT : MATRIX) \ureturn\n MATRIX; -- see 3.6 Examples of in parameters with default expressions: \uprocedure\n PRINT_HEADER(PAGES : \uin\n NATURAL; HEADER : \uin\n LINE := (1 .. LINE'LAST => ' '); -- see 3.6 CENTER : \uin\n BOOLEAN := TRUE); \uNotes:\n The \vevaluation\v411. of default expressions is caused by certain \vsubprogram\v606. \vcalls\v606., as described in section 6.4.2 (default expressions are not evaluated during the elaboration of the subprogram declaration). All subprograms can be called recursively and are reentrant. 6.2 \uFormal Parameter Modes\n The value of an \vobject\v302. is said to be read when this value is \vevaluated\v411.; it is also said to be read when one of its \vsubcomponents\v305. is read. The value of a \vvariable\v303. is said to be updated when an \vassignment\v502. is performed to the variable, and also (indirectly) when the variable is used as \vactual\v607. \vparameter\v607. of a \vsubprogram call\v606. or \ventry call statement\v905. that updates its value; it is also said to be updated when one of its subcomponents is updated. A \vformal parameter\v601. of a subprogram has one of the three following \vmodes\v601.: \uin\n The formal parameter is a constant and permits only reading of the value of the associated actual parameter. \uin out\n The formal parameter is a variable and permits both reading and updating of the value of the associated actual parameter. \uout\n The formal parameter is a variable and permits updating of the value of the associated actual parameter. The value of a scalar parameter that is not updated by the call is undefined upon return; the same holds for the value of a scalar subcomponent, other than a \vdiscriminant\v326.. Reading the bounds and discriminants of the formal parameter and of its subcomponents is allowed, but no other reading. For a scalar parameter, the above effects are achieved by copy: at the start of each call, if the mode is in or in out, the value of the actual parameter is copied into the associated formal parameter; then after normal completion of the \vsubprogram body\v603., if the mode is in out or out, the value of the formal parameter is copied back into the associated actual parameter. For a parameter whose type is an \vaccess type\v330., copy-in is used for all three modes, and copy-back for the modes in out and out. For a parameter whose type is an \varray\v321., \vrecord\v325., or \vtask type\v902., an implementation may likewise achieve the above effects by copy, as for \vscalar types\v310.. In addition, if copy is used for a parameter of mode out, then copy-in is required at least for the bounds and discriminants of the actual parameter and of its subcomponents, and also for each subcomponent whose type is an access type. Alternatively, an implementation may achieve these effects by reference, that is, by arranging that every use of the formal parameter (to read or to update its value) be treated as a use of the associated actual parameter, throughout the execution of the subprogram call. The language does not define which of these two mechanisms is to be adopted for parameter passing, nor whether different calls to the same subprogram are to use the same mechanism. The execution of a program is \verroneous\v108. if its effect depends on which mechanism is selected by the implementation. For a parameter whose type is a \vprivate type\v704., the above effects are achieved according to the rule that applies to the corresponding full type declaration. Within the body of a subprogram, a formal parameter is subject to any \vconstraint\v305. resulting from the \vtype mark\v307. given in its \vparameter\v601. \vspecification\v601.. For a formal parameter of an \vunconstrained array type\v321., the bounds are obtained from the actual parameter, and the formal parameter is constrained by these \vbounds (see 3.6.1)\v322.. For a formal parameter whose declaration specifies an \vunconstrained (private or record) type with\v326. \vdiscriminants\v326., the discriminants of the formal parameter are initialized with the values of the corresponding discriminants of the actual parameter; the formal parameter is unconstrained if and only if the mode is in out or out and the variable name given for the actual parameter denotes an \vunconstrained variable\v303. (see 3.7.1 and 6.4.1). If the actual parameter of a subprogram call is a subcomponent that \vdepends\v326. \von discriminants\v326. of an unconstrained record variable, then the execution of the call is erroneous if the value of any of the discriminants of the variable is changed by this execution; this rule does not apply if the mode is in and the type of the subcomponent is a scalar type or an access type. \uNotes:\n For parameters of array and record types, the parameter passing rules have these consequences: - If the execution of a subprogram is abandoned as a result of an \vexception\v1100., the final value of an actual parameter of such a type can be either its value before the call or a value assigned to the formal parameter during the execution of the subprogram. - If no actual parameter of such a type is accessible by more than one path, then the effect of a subprogram call (unless abandoned) is the same whether or not the implementation uses copying for parameter passing. If, however, there are multiple access paths to such a parameter (for example, if a \vglobal\v801. variable, or another formal parameter, refers to the same actual parameter), then the value of the formal is undefined after updating the actual other than by updating the formal. A program using such an undefined value is erroneous. The same parameter modes are defined for formal parameters of entries (see 9.5) with the same meaning as for subprograms. Different parameter modes are defined for \vgeneric formal parameters\v1201.. For all modes, if an actual parameter designates a \vtask\v900., the associated formal parameter designates the same task; the same holds for a subcomponent of an actual parameter and the corresponding subcomponent of the associated formal parameter. 6.3 \uSubprogram Bodies\n A \vsubprogram\v600. body specifies the execution of a subprogram. subprogram_body ::= subprogram_specification \uis\n [declarative_part] \ubegin\n sequence_of_statements [\uexception\n exception_handler {exception_handler}] \uend\n [designator]; The \vdeclaration\v301. of a subprogram is optional. In the absence of such a declaration, the \vsubprogram specification\v601. of the subprogram body (or \vbody\v1004. \vstub\v1004.) acts as the declaration. For each \vsubprogram declaration\v601., there must be a corresponding body (except for a subprogram written in another language, as explained in section 13.9). If both a declaration and a body are given, the subprogram specification of the body must \vconform\v604. to the subprogram specification of the declaration (see section 6.3.1 for conformance rules). If a \vdesignator\v601. appears at the end of a subprogram body, it must repeat the designator of the subprogram specification. The \velaboration\v333. of a subprogram body has no other effect than to establish that the body can from then on be used for the execution of calls of the subprogram. The execution of a subprogram body is invoked by a \vsubprogram call\v606.. For this execution, after establishing the association between \vformal parameters\v601. and \vactual parameters\v607., the \vdeclarative part\v333. of the body is elaborated, and the \vsequence of statements\v501. of the body is then executed. Upon completion of the body, return is made to the caller (and any necessary copying back of formal to actual parameters occurs (see 6.2)). The optional \vexception handlers\v1102. at the end of a subprogram body handle \vexceptions\v1100. raised during the execution of the sequence of statements of the subprogram body (see 11.4). Note: It follows from the \vvisibility\v803. rules that if a subprogram declared in a \vpackage\v700. is to be visible outside the package, a subprogram specification must be given in the \vvisible part\v702. of the package. The same rules dictate that a subprogram declaration must be given if a call of the subprogram occurs textually before the subprogram body (the declaration must then occur earlier than the call in the program text). The rules given in sections 3.9 and 7.1 imply that a subprogram declaration and the corresponding body must both \voccur immediately\v801. \vwithin\v801. the same \vdeclarative\v801. \vregion\v801.. Example of subprogram body: \uprocedure\n PUSH(E : \uin\n ELEMENT_TYPE; S : \uin out\n STACK) \uis\n \ubegin\n \uif\n S.INDEX = S.SIZE \uthen\n \uraise\n STACK_OVERFLOW; \uelse\n S.INDEX := S.INDEX + 1; S.SPACE(S.INDEX) := E; \uend if\n; \uend\n PUSH; More details: 6.3.1 \vConformance Rules\v604. 6.3.2 \vInline Expansion of Subprograms\v605. 6.3.1 \uConformance Rules\n Whenever the language rules require or \vallow\v108. the specification of a given subprogram to be provided in more than one place, the following variations are allowed at each place: - A \vnumeric literal\v204. can be replaced by a different numeric literal if and only if both have the same value. - A \vsimple name\v401. can be replaced by an \vexpanded name\v404. in which this simple \vname\v401. is the \vselector\v404., if and only if at both places the meaning of the simple name is given by the same \vdeclaration\v301.. - A string literal given as an \voperator symbol\v601. can be replaced by a different string literal if and only if both represent the same operator. Two \vsubprogram specifications\v601. are said to conform if, apart from \vcomments\v209. and the above allowed variations, both specifications are formed by the same sequence of \vlexical elements\v200., and corresponding lexical elements are given the same meaning by the \vvisibility\v803. and \voverloading\v610. rules. Conformance is likewise defined for \vformal parts\v601., \vdiscriminant parts\v326., and type marks (for \vdeferred constants\v707. and for \vactual parameters\v606. that have the form of a \vtype conversion\v419. (see 6.4.1)). \uNotes:\n A simple name can be replaced by an expanded name even if the simple name is itself the \vprefix\v401. of a \vselected component\v404.. For example, Q.R can be replaced by P.Q.R if Q is declared immediately within P. The following specifications do not conform since they are not formed by the same sequence of lexical elements: \uprocedure\n P(X,Y : INTEGER) \uprocedure\n P(X : INTEGER; Y : INTEGER) \uprocedure\n P(X,Y : \uin\n INTEGER) 6.3.2 \uInline Expansion of Subprograms\n The \vpragma\v210. INLINE is used to indicate that inline expansion of the \vsubprogram body\v603. is desired for every call of each of the named \vsubprograms\v600.. The form of this pragma is as follows: \upragma\n INLINE (name {, name}); Each \vname\v401. is either the name of a subprogram or the name of a \vgeneric\v1201. \vsubprogram\v1201.. The pragma INLINE is only \vallowed\v108. at the place of a \vdeclarative item\v333. in a \vdeclarative part\v333. or \vpackage specification\v701., or after a \vlibrary unit\v1001. in a \vcompilation\v1001., but before any subsequent \vcompilation\v1001. \vunit\v1001.. If the pragma appears at the place of a declarative item, each name must denote a subprogram or a generic subprogram declared by an earlier declarative item of the same declarative part or package specification. If several (\voverloaded\v610.) subprograms satisfy this requirement, the pragma applies to all of them. If the pragma appears after a given library unit, the only name allowed is the name of this unit. If the name of a generic subprogram is mentioned in the pragma, this indicates that inline expansion is desired for calls of all subprograms obtained by \vinstantiation\v1206. of the named \vgeneric unit\v1200.. The meaning of a subprogram is not changed by the pragma INLINE. For each call of the named subprograms, an implementation is free to follow or to ignore the recommendation expressed by the pragma. (Note, in particular, that the recommendation cannot generally be followed for a recursive subprogram.) 6.4 \uSubprogram Calls\n A \vsubprogram\v600. call is either a procedure call statement or a function call; it invokes the execution of the corresponding subprogram body. The call specifies the association of the actual parameters, if any, with \vformal\v601. \vparameters\v601. of the subprogram. procedure_call_statement ::= procedure_name [actual_parameter_part]; function_call ::= function_name [actual_parameter_part] actual_parameter_part ::= (parameter_association {, parameter_association}) parameter_association ::= [formal_parameter =>] actual_parameter formal_parameter ::= parameter_simple_name actual_parameter ::= \vexpression\v410. | \vvariable_name\v303. | \vtype_mark\v307.(variable_name) Each parameter association associates an actual parameter with a corresponding formal parameter. A parameter association is said to be named if the formal parameter is named explicitly; it is otherwise said to be positional. For a positional association, the actual parameter corresponds to the formal parameter with the same position in the \vformal\v601. \vpart\v601.. Named associations can be given in any order, but if both positional and named associations are used in the same call, positional associations must occur first, at their normal position. Hence once a named association is used, the rest of the call must use only named associations. For each formal parameter of a subprogram, a subprogram call must specify exactly one corresponding actual parameter. This actual parameter is specified either explicitly, by a parameter association, or, in the absence of such an association, by a \vdefault expression\v601. (see 6.4.2). The parameter associations of a subprogram call are evaluated in some order that is not defined by the language. Similarly, the language rules do not define in which order the values of in out or out parameters are copied back into the corresponding actual parameters (when this is done). Examples of procedure calls: TRAVERSE_TREE; -- see 6.1 TABLE_MANAGER.INSERT(E); -- see 7.5 PRINT_HEADER(128, TITLE, TRUE); -- see 6.1 SWITCH(FROM => X, TO => NEXT); -- see 6.1 PRINT_HEADER(128, HEADER => TITLE, CENTER => TRUE -- see 6.1 PRINT_HEADER(HEADER => TITLE, CENTER => TRUE, PAGES => 128); -- see 6.1 Examples of function calls: DOT_PRODUCT(U, V) -- see 6.1 and 6.5 CLOCK -- see 9.6 More details: 6.4.1 \vParameter Associations\v607. 6.4.2 \vDefault Parameters\v608. 6.4.1 \uParameter Associations\n Each \vactual parameter\v606. must have the same \vtype\v305. as the corresponding \vformal\v601. \vparameter\v601.. An actual \vparameter associated\v606. with a formal parameter of \vmode\v601. in must be an \vexpression\v410.; it is evaluated before the call. An actual parameter associated with a formal parameter of mode in out or out must be either the \vname\v401. of a \vvariable\v303., or of the form of a \vtype\v419. \vconversion\v419. whose argument is the name of a variable. In either case, for the mode in out, the variable must not be a formal parameter of mode out or a subcomponent thereof. For an actual parameter that has the form of a type conversion, the \vtype mark\v307. must \vconform\v604. to the type mark of he formal parameter; the allowed operand and target types are the same as for type conversions (see 4.6). The variable name given for an actual parameter of mode in out or out is evaluated before the call. If the actual parameter has the form of a type conversion, then before the call, for a parameter of mode in out, the variable is converted to the specified type; after (normal) completion of the subprogram body, for a parameter of mode in out or out, the formal parameter is converted back to the type of the variable. (The type specified in the conversion must be that of the formal parameter.) The following \vconstraint\v305. checks are performed for parameters of scalar and access types: - Before the call: for a parameter of mode in or in out, it is checked that the value of the actual parameter belongs to the \vsubtype\v305. of the formal parameter. - After (normal) completion of the subprogram body: for a parameter of mode in out or out, it is checked that the value of the formal parameter belongs to the subtype of the actual variable. In the case of a type conversion, the value of the formal parameter is converted back and the check applies to the result of the conversion. In each of the above cases, the execution of the program is \verroneous\v108. if the checked \vvalue is undefined\v303.. For other types, for all modes, a check is made before the call as for scalar and access types; no check is made upon return. The \vexception CONSTRAINT_ERROR\v1101. is raised at the place of the subprogram call if either of these checks fails. Note: For \varray types\v321. and for types with \vdiscriminants\v326., the check before the call is sufficient (a check upon return would be redundant) if the type mark of the formal parameter denotes a \vconstrained subtype\v305., since neither \varray\v321. \vbounds\v321. nor discriminants can then vary. If this type mark denotes an \vunconstrained array type\v321., the formal parameter is constrained with the bounds of the corresponding actual parameter and no check (neither before the call nor upon return) is needed (see 3.6.1). Similarly, no check is needed if the type mark denotes an \vunconstrained\v326. \vtype with discriminants\v326., since the formal parameter is then constrained exactly as the corresponding actual parameter (see 3.7.1). 6.4.2 \uDefault Parameters\n If a \vparameter specification\v601. includes a default expression for a parameter of \vmode\v601. in, then corresponding \vsubprogram calls\v606. need not include a \vparameter association\v606. for the parameter. If a parameter association is thus omitted from a call, then the rest of the call, following any initial \vpositional associations\v606., must use only \vnamed associations\v606.. For any omitted parameter association, the default expression is evaluated before the call and the resulting value is used as an implicit \vactual\v607. \vparameter\v607.. Examples of procedures with default values: \uprocedure\n ACTIVATE(PROCESS : \uin\n PROCESS_NAME; AFTER : \uin\n PROCESS_NAME := NO_PROCESS; WAIT : \uin\n DURATION := 0.0; PRIOR : \uin\n BOOLEAN := FALSE); \uprocedure\n PAIR(LEFT, RIGHT : PERSON_NAME := \unew\n PERSON); Examples of their calls: ACTIVATE(X); ACTIVATE(X, AFTER => Y); ACTIVATE(X, WAIT => 60.0, PRIOR => TRUE); ACTIVATE(X, Y, 10.0, FALSE); PAIR; PAIR(LEFT => \unew\n PERSON, RIGHT => \unew\n PERSON); Note: If a default expression is used for two or more parameters in a multiple parameter specification, the default expression is evaluated once for each omitted parameter. Hence in the above examples, the two calls of PAIR are equivalent. 6.5 \uFunction Subprograms\n A \vfunction\v601. is a subprogram that returns a value (the result of the \vfunction\v606. \vcall\v606.). The \vspecification of a function\v601. starts with the reserved word function, and the parameters, if any, must have the \vmode\v601. in (whether this mode is specified explicitly or implicitly). The \vstatements\v500. of the \vfunction body\v603. (excluding statements of program units that are inner to the function body) must include one or more \vreturn statements\v509. specifying the returned value. The \vexception PROGRAM_ERROR\v1101. is raised if a function body is left otherwise than by a return statement. This does not apply if the execution of the function is abandoned as a result of an \vexception\v1100.. Example: \ufunction\n DOT_PRODUCT(LEFT, RIGHT : VECTOR) \ureturn\n REAL \uis\n SUM : REAL := 0.0; \ubegin\n CHECK(LEFT'FIRST = RIGHT'FIRST \uand\n LEFT'LAST = RIGHT'LAST); \ufor\n J \uin\n LEFT'RANGE \uloop\n SUM := SUM + LEFT(J)*RIGHT(J); \uend loop\n; \ureturn\n SUM; \uend\n DOT_PRODUCT; 6.6 \uParameter and Result Type Profile - Overloading of Subprograms\n Two formal parts are said to have the same parameter type profile if and only if they have the same number of parameters, and at each parameter position corresponding parameters have the same \vbase type\v305.. A \vsubprogram\v600. or \ventry\v905. has the same parameter and result \vtype\v305. profile as another subprogram or entry if and only if both have the same parameter type profile, and either both are \vfunctions\v609. with the same result base type, or neither of the two is a function. The same subprogram identifier or \voperator symbol\v601. can be used in several \vsubprogram specifications\v601.. The \videntifier\v203. or operator symbol is then said to be \voverloaded\v807.; the subprograms that have this identifier or operator symbol are also said to be overloaded and to overload each other. As explained in section 8.3, if two subprograms overload each other, one of them can hide the other only if both subprograms have the same parameter and result type profile (see section 8.3 for the other requirements that must be met for \vhiding\v803.). A call to an overloaded subprogram is ambiguous (and therefore \villegal\v108.) if the name of the subprogram, the number of \vparameter associations\v606., the types and the order of the \vactual parameters\v607., the names of the \vformal\v601. \vparameters\v601. (if named associations are used), and the result type (for functions) are not sufficient to determine exactly one (overloaded) subprogram specification. Examples of overloaded subprograms: \uprocedure\n PUT(X : INTEGER); \uprocedure\n PUT(X : STRING); \uprocedure\n SET(TINT : COLOR); \uprocedure\n SET(SIGNAL : LIGHT); Examples of calls: PUT(28); PUT("no possible ambiguity here"); SET(TINT => RED); SET(SIGNAL => RED); SET(COLOR'(RED)); -- SET(RED) would be ambiguous since RED may -- denote a value either of type COLOR or of type LIGHT \uNotes:\n The notion of parameter and result type profile does not include parameter names, parameter modes, parameter subtypes, default expressions and their presence or absence. Ambiguities may (but need not) arise when actual parameters of the call of an overloaded subprogram are themselves overloaded \vfunction calls\v606., \vliterals\v406., or \vaggregates\v407.. Ambiguities may also (but need not) arise when several overloaded subprograms belonging to different \vpackages\v700. are visible. These ambiguities can usually be resolved in several ways: \vqualified\v420. \vexpressions\v420. can be used for some or all actual parameters, and for the result, if any; the name of the subprogram can be expressed more explicitly as an expanded name; finally, the subprogram can be renamed. 6.7 \uOverloading of Operators\n The \vdeclaration\v301. of a function whose \vdesignator\v601. is an \voperator symbol\v601. is used to overload an \voperator\v411.. The sequence of \vcharacters\v201. of the operator symbol must be either a \vlogical\v411., a \vrelational\v411., a \vbinary adding\v411., a \vunary\v411. \vadding\v411., a \vmultiplying\v411., or a \vhighest precedence operator\v411.. Neither \vmembership tests\v411. nor the \vshort-circuit control forms\v411. are \vallowed\v108. as function designators. The subprogram specification of a unary operator must have a single parameter. The subprogram specification of a binary operator must have two parameters; for each use of this operator, the first parameter takes the left operand as \vactual parameter\v607., the second parameter takes the right operand. Similarly, a generic function instantiation whose designator is an operator symbol is only allowed if the specification of the generic function has the corresponding number of parameters. Default expressions are not allowed for the parameters of an operator (whether the operator is declared with an explicit subprogram specification or by a generic instantiation). For each of the operators "+" and "-", \voverloading\v610. is allowed both as a unary and as a binary operator. The explicit \vdeclaration of a function\v601. that overloads the \vequality operator\v411. "=", other than by a renaming declaration, is only allowed if both parameters are of the same \vlimited type\v708.. An overloading of equality must deliver a result of the \vpredefined type BOOLEAN\v313.; it also implicitly overloads the \vinequality operator\v413. "/=" so that this still gives the \vcomplementary result\v413. to the equality operator. Explicit overloading of the inequality operator is not allowed. A renaming declaration whose designator is the equality operator is only allowed to rename another equality operator. (For example, such a renaming declaration can be used when equality is \vvisible by selection\v803. but not \vdirectly visible\v803..) Note: Overloading of relational operators does not affect basic comparisons such as testing for membership in a range or the choices in a case statement. \uExamples:\n \ufunction\n "+" (LEFT, RIGHT : MATRIX) \ureturn\n MATRIX; \ufunction\n "+" (LEFT, RIGHT : VECTOR) \ureturn\n VECTOR; -- assuming that A, B, and C are of the type VECTOR -- the three following assignments are equivalent A := B + C; A := "+"(B, C); A := "+"(LEFT => B, RIGHT => C); 7. \uPackages\n Packages are one of the four forms of \vprogram unit\v600., of which programs can be composed. The other forms are \vsubprograms\v600., \vtask units\v900., and \vgeneric\v1200. \vunits\v1200.. Packages allow the specification of groups of logically related entities. In their simplest form packages specify pools of common object and \vtype\v306. \vdeclarations\v306.. More generally, packages can be used to specify groups of related entities including also subprograms that can be called from outside the package, while their inner workings remain concealed and protected from outside users. More details: 7.1 \vPackage Structure\v701. 7.2 \vPackage Specifications and Declarations\v702. 7.3 \vPackage Bodies\v703. 7.4 \vPrivate Type and Deferred Constant Declarations\v704. 7.5 \vExample of a Table Management Package\v709. 7.6 \vExample of a Text Handling Package\v710. 7.1 \uPackage Structure\n A package is generally provided in two parts: a package specification and a \vpackage body\v703.. Every package has a package specification, but not all packages have a package body. package_declaration ::= package_specification; package_specification ::= \upackage\n identifier \uis\n {\vbasic_declarative_item\v333.} [\uprivate\n {basic_declarative_item}] \uend\n [package_simple_name] package_body ::= \upackage body\n package_simple_name \uis\n [declarative_part] [\ubegin\n \vsequence_of_statements\v501. [\uexception\n exception_handler {\vexception_handler\v1102.}]] \uend\n [package_simple_name]; The simple name at the start of a package body must repeat the package \videntifier\v203.. Similarly if a \vsimple name\v401. appears at the end of the package specification or body, it must repeat the package identifier. If a \vsubprogram declaration\v601., a package declaration, a \vtask declaration\v901., or a \vgeneric declaration\v1201. is a \vdeclarative item\v333. of a given package specification, then the body (if there is one) of the \vprogram unit\v600. declared by the declarative item must itself be a declarative item of the \vdeclarative part\v333. of the body of the given package. \uNotes:\n A simple form of package, specifying a pool of \vobjects\v302. and \vtypes\v305., does not require a package body. One of the possible uses of the sequence of statements of a package body is to initialize such objects. For each subprogram declaration there must be a corresponding body (except for a subprogram written in another language, as explained in section 13.9). If the body of a program unit is a \vbody stub\v1004., then a separately compiled \vsubunit\v1004. containing the corresponding \vproper body\v333. is required for the program unit (see 10.2). A body is not a basic declarative item and so cannot appear in a package specification. A package declaration is either a library package (see 10.2) or a declarative item declared within another program unit. 7.2 \uPackage Specifications and Declarations\n The first list of \vdeclarative items\v333. of a \vpackage specification\v701. is called the visible part of the \vpackage\v700.. The optional list of declarative items after the reserved word private is called the private part of the package. An entity declared in the private part of a package is not visible outside the package itself (a \vname\v401. denoting such an entity is only possible within the package). In contrast, \vexpanded names\v404. denoting entities declared in the visible part can be used even outside the package; furthermore, \vdirect\v803. \vvisibility\v803. of such entities can be achieved by means of \vuse clauses\v804. (see 4.1.3 and 8.4). The \velaboration\v333. of a \vpackage declaration\v701. consists of the elaboration of its \vbasic declarative items\v333. in the given order. \uNotes:\n The visible part of a package contains all the information that another program unit is able to know about the package. A package consisting of only a package specification (that is, without a package body) can be used to represent a group of common \vconstants\v303. or \vvariables\v303., or a common pool of objects and types, as in the examples below. Example of a package describing a group of common variables: \upackage\n PLOTTING_DATA \uis\n PEN_UP : BOOLEAN; CONVERSION_FACTOR, X_OFFSET, Y_OFFSET, X_MIN, Y_MIN, X_MAX, Y_MAX: REAL; -- see 3.5.7 X_VALUE : \uarray\n (1 .. 500) \uof\n REAL; Y_VALUE : \uarray\n (1 .. 500) \uof\n REAL; \uend\n PLOTTING_DATA; Example of a package describing a common pool of objects and types: \upackage\n WORK_DATA \uis\n \utype\n DAY \uis\n (MON, TUE, WED, THU, FRI, SAT, SUN); \utype\n HOURS_SPENT \uis delta\n 0.25 \urange\n 0.0 .. 24.0; \utype\n TIME_TABLE \uis array\n (DAY) \uof\n HOURS_SPENT; WORK_HOURS : TIME_TABLE; NORMAL_HOURS : \uconstant\n TIME_TABLE := (MON .. THU => 8.25, FRI => 7.0, SAT | SUN => 0.0); \uend\n WORK_DATA; 7.3 \uPackage Bodies\n In contrast to the entities declared in the \vvisible part\v702. of a \vpackage\v701. \vspecification\v701., the entities declared in the package body are only visible within the package body itself. As a consequence, a package with a package body can be used for the construction of a group of related \vsubprograms\v600. (a package in the usual sense), in which the logical operations available to the users are clearly isolated from the internal entities. For the \velaboration\v301. of a package body, its \vdeclarative part\v333. is first elaborated, and its \vsequence of statements\v501. (if any) is then executed. The optional \vexception handlers\v1102. at the end of a package body service exceptions raised during the execution of the sequence of statements of the package body. \uNotes:\n A \vvariable\v303. declared in the body of a package is only visible within this body and, consequently, its value can only be changed within the package body. In the absence of local tasks, the value of such a variable remains unchanged between calls issued from outside the package to subprograms declared in the visible part. The properties of such a variable are similar to those of an "own" variable of Algol 60. The elaboration of the body of a subprogram declared in the visible part of a package is caused by the elaboration of the body of the package. Hence a call of such a subprogram by an outside \vprogram unit\v600. raises the \vexception\v1100. \vPROGRAM_ERROR\v1101. if the call takes place before the elaboration of the package body (see 3.9). Example of a package: \upackage\n RATIONAL_NUMBERS \uis\n \utype\n RATIONAL \uis\n \urecord\n NUMERATOR : INTEGER; DENOMINATOR : POSITIVE; \uend record\n; \ufunction\n EQUAL(X,Y : RATIONAL) \ureturn\n BOOLEAN; \ufunction\n "/" (X,Y : INTEGER) \ureturn\n RATIONAL; -- to construct a rational number \ufunction\n "+" (X,Y : RATIONAL) \ureturn\n RATIONAL; \ufunction\n "-" (X,Y : RATIONAL) \ureturn\n RATIONAL; \ufunction\n "*" (X,Y : RATIONAL) \ureturn\n RATIONAL; \ufunction\n "/" (X,Y : RATIONAL) \ureturn\n RATIONAL; \uend\n; \upackage body\n RATIONAL_NUMBERS \uis\n \uprocedure\n SAME_DENOMINATOR (X,Y : \uin out\n RATIONAL) \uis\n \ubegin\n -- reduces X and Y to the same denominator: ... \uend\n; \ufunction\n EQUAL(X,Y : RATIONAL) \ureturn\n BOOLEAN \uis\n U,V : RATIONAL; \ubegin\n U := X; V := Y; SAME_DENOMINATOR (U,V); \ureturn\n U.NUMERATOR = V.NUMERATOR; \uend\n EQUAL; \ufunction\n "/" (X,Y : INTEGER) \ureturn\n RATIONAL \uis\n \ubegin\n \uif\n Y > 0 \uthen\n \ureturn\n (NUMERATOR => X, DENOMINATOR => Y); \uelse\n \ureturn\n (NUMERATOR => -X, DENOMINATOR => -Y); \uend if\n; \uend\n "/"; \ufunction\n "+" (X,Y : RATIONAL) \ureturn\n RATIONAL \uis\n ... \uend\n "+"; \ufunction\n "-" (X,Y : RATIONAL) \ureturn\n RATIONAL \uis\n ... \uend\n "-"; \ufunction\n "*" (X,Y : RATIONAL) \ureturn\n RATIONAL \uis\n ... \uend\n "*"; \ufunction\n "/" (X,Y : RATIONAL) \ureturn\n RATIONAL \uis\n ... \uend\n "/"; \uend\n RATIONAL_NUMBERS; 7.4 \uPrivate Type and Deferred Constant Declarations\n The declaration of a \vtype\v305. as a \vprivate type\v705. in the visible part of a \vpackage\v700. serves to separate the characteristics that can be used directly by outside \vprogram units\v600. (that is, the logical properties) from other characteristics whose direct use is confined to the package (the details of the definition of the type itself). \vDeferred constant\v707. \vdeclarations\v301. declare \vconstants\v303. of private types. private_type_declaration ::= \utype\n identifier [\vdiscriminant_part\v326.] \uis\n [limited] \uprivate\n; deferred_constant_declaration ::= identifier_list : \uconstant\n \vtype_mark\v307.; A private type declaration is only allowed as a \vdeclarative item\v333. of the \vvisible part\v702. of a package, or as the \vgeneric parameter declaration\v1201. for a \vgeneric formal type\v1201. in a \vgeneric formal part\v1201. The type mark of a deferred constant declaration must denote a private type or a \vsubtype\v305. of a private type; a deferred constant declaration and the declaration of the corresponding private type must both be declarative items of the visible part of the same package. A deferred constant declaration with several \videntifiers\v203. is equivalent to a sequence of single deferred constant declarations as explained in section 3.2. Examples of private type declarations: \utype\n KEY \uis private\n; \utype\n FILE_NAME \uis limited private\n; Example of deferred constant declaration: NULL_KEY : \uconstant\n KEY; More details: 7.4.1 \vPrivate Types\v705. 7.4.2 \vOperations of a Private Type\v706. 7.4.3 \vDeferred Constants\v707. 7.4.4 \vLimited Types\v708. 7.4.1 \uPrivate Types\n If a private \vtype declaration\v306. is given in the \vvisible part\v702. of a \vpackage\v700., then a corresponding declaration of a \vtype\v305. with the same \videntifier\v203. must appear as a \vdeclarative item\v333. of the \vprivate part\v702. of the package. The corresponding declaration must be either a full type declaration or the declaration of a task type. In the rest of this section explanations are given in terms of \vfull type declarations\v306.; the same rules apply also to declarations of task types. A private type declaration and the corresponding full type declaration define a single type. The private type declaration, together with the visible part, define the \voperations\v305. that are available to outside program units (see section 7.4.2 on the operations that are available for private types). On the other hand, the full type declaration defines other operations whose direct use is only possible within the package itself. If the \vprivate type\v704. declaration includes a \vdiscriminant part\v326., the full declaration must include a discriminant part that \vconforms\v604. (see 6.3.1 for the conformance rules) and its \vtype definition\v306. must be a \vrecord type\v325. \vdefinition\325.. Conversely, if the \vprivate type declaration\v704. does not include a discriminant part, the type declared by the full type declaration (the full type) must not be an unconstrained type with discriminants. The full type must not be an unconstrained \varray type\v321.. A \vlimited type\v708. (in particular a task type) is allowed for the full type only if the \vreserved word\v211. limited appears in the private type declaration (see 7.4.4). Within the \vspecification of the package\v701. that declares a private type and before the end of the corresponding full type declaration, a restriction applies to the use of a \vname\v401. that denotes the private type or a \vsubtype\v305. of the private type and, likewise, to the use of a name that denotes any type or subtype that has a \vsubcomponent\v305. of the private type. The only allowed occurrences of such a name are in a \vdeferred constant declaration\v707., a type or \vsubtype declaration\v307., a \vsubprogram specification\v601., or an \ventry\v905. \vdeclaration\v905.; moreover, occurrences within \vderived type definitions\v309. or within simple \vexpressions\v410. are not allowed. The \velaboration\v333. of a private type declaration creates a private type. If the private type declaration has a discriminant part, this elaboration includes that of the discriminant part. The elaboration of the full type declaration consists of the elaboration of the type definition; the discriminant part, if any, is not elaborated (since the conforming discriminant part of the private type declaration has already been elaborated). \uNotes:\n It follows from the given rules that neither the declaration of a \vvariable\v303. of a private type, nor the creation by an \vallocator\v421. of an object of the private type are allowed before the full declaration of the type. Similarly before the full declaration, the name of the private type cannot be used in a \vgeneric instantiation\v1206. or in a \vrepresentation clause\v1301.. 7.4.2 \uOperations of a Private Type\n The operations that are \vimplicitly declared\v301. by a private type \vdeclaration\v301. include basic operations. These are the operations involved in \vassignment\v502. (unless the reserved word limited appears in the declaration), \vmembership\v411. \vtests\v411., selected \vcomponents\v305. for the selection of any \vdiscriminant\v305., \vqualification\v420., and explicit \vconversions\v419.. For a \vprivate type\v704. T, the basic \voperations\v305. also include the \vattributes\v405. T'BASE (see 3.3.3) and T'SIZE (see 13.7.2). For an object A of a private type, the \vbasic operations\v308. include the attribute A'CONSTRAINED if the private type has discriminants (see 3.7.4), and in any case, the attributes A'SIZE and A'ADDRESS (see 13.7.2). Finally, the operations implicitly declared by a \vprivate type declaration\v704. include the predefined comparison for \vequality\v413. and inequality unless the reserved word limited appears in the private type declaration. The above operations, together with \vsubprograms\v600. that have a parameter or result of the private type and that are declared in the \vvisible\v702. part of the \vpackage\v700., are the only operations from the package that are available outside the package for the private type. Within the package that declares the private type, the additional operations implicitly declared by the full type declaration are also available. However, the redefinition of these implicitly declared operations is allowed within the same \vdeclarative region\v801., including between the private type declaration and the corresponding full declaration. An explicitly declared subprogram hides an implicitly declared operation that has the same parameter and result type profile (this is only possible if the implicitly declared operation is a \vderived subprogram\v309. or a \vpredefined\v411. \voperator\v411.). If a composite type has subcomponents of a private type and is declared outside the package that declares the private type, then the operations that are implicitly declared by the declaration of the composite type include all operations that only depend on the characteristics that result from the private type declaration alone. (For example the operator < is not included for a one-dimensional array type.) If the composite type is itself declared within the package that declares the private type (including within an inner package or generic package), then additional operations that depend on the characteristics of the full type are implicitly declared, as required by the rules applicable to the composite type (for example the operator < is declared for a one-dimensional array type if the \vfull type\v705. is discrete). These additional operations are implicitly declared at the earliest place within the \vimmediate scope\v802. of the composite type and after the \vfull type declaration\v306.. The same rules apply to the operations that are implicitly declared for an access type whose designated type is a private type or a type declared by an \vincomplete type declaration\v331.. For every private type or subtype T the following attribute is defined: T'CONSTRAINED Yields the value FALSE if T denotes an unconstrained nonformal private type with discriminants; also yields the value FALSE if T denotes a generic formal private type, and the associated actual subtype is either an unconstrained type with discriminants or an unconstrained array type; yields the value TRUE otherwise. The value of this attribute is of the predefined type BOOLEAN. Note: A private type declaration and the corresponding full type declaration define two different views of one and the same type. Outside of the defining package the characteristics of the type are those defined by the visible part. Within these outside program units the type is just a private type and any language rule that applies only to another class of types does not apply. The fact that the full declaration might implement the private type with a type of a particular class (for example, as an array type) is only relevant within the package itself. The consequences of this actual implementation are, however, valid everywhere. For example: any default initialization of components takes place; the attribute SIZE provides the size of the full type; \vtask\v904. \vdependence\v904. rules still apply to components that are task objects. Example: \upackage\n KEY_MANAGER \uis\n \utype\n KEY \uis private\n; NULL_KEY : constant KEY; \uprocedure\n GET_KEY(K : \uout\n KEY); \ufunction\n "<" (X, Y : KEY) \ureturn\n BOOLEAN; \uprivate\n \utype\n KEY \uis new\n NATURAL; NULL_KEY : \uconstant\n KEY := 0; \uend\n; \upackage body\n KEY_MANAGER \uis\n LAST_KEY : KEY := 0; \uprocedure\n GET_KEY(K : out KEY) \uis\n \ubegin\n LAST_KEY := LAST_KEY + 1; K := LAST_KEY; \uend\n GET_KEY; \ufunction\n "<" (X, Y : KEY) \ureturn\n BOOLEAN \uis\n \ubegin\n \ureturn\n INTEGER(X) < INTEGER(Y); \uend\n "<"; \uend\n KEY_MANAGER; Notes on the example: Outside of the package KEY_MANAGER, the operations available for objects of type KEY include assignment, the comparison for equality or inequality, the procedure GET_KEY and the operator "<"; they do not include other \vrelational operators\v411. such as ">=", or arithmetic operators. The explicitly declared operator "<" hides the predefined operator "<" implicitly declared by the full type declaration. Within the body of the function, an explicit conversion of X and Y to the type INTEGER is necessary to invoke the "<" operator of this type. Alternatively, the result of the function could be written as not (X >= Y), since the operator ">=" is not redefined. The value of the variable LAST_KEY, declared in the package body, remains unchanged between calls of the procedure GET_KEY. (See also the Notes of section 7.3.) 7.4.3 \uDeferred Constants\n If a deferred constant declaration is given in the \vvisible part\v702. of a \vpackage\v700. then a constant declaration (that is, an object declaration declaring a constant object, with an explicit initialization) with the same \videntifier\v203. must appear as a \vdeclarative item\v333. of the \vprivate part\v702. of the package. This \vobject declaration\v303. is called the full declaration of the deferred constant. The \vtype mark\v307. given in the full declaration must \vconform\v604. to that given in the deferred \vconstant declaration\v604. (see 6.3.1). Multiple or single declarations are allowed for the deferred and the full declarations, provided that the equivalent single declarations conform. Within the \vspecification of the package\v701. that declares a deferred constant and before the end of the corresponding full declaration, the use of a name that denotes the \vdeferred constant\v704. is only allowed in the default expression for a \vrecord component\v325. or for a \vformal parameter\v601. (not for a \vgeneric formal parameter\v1201.). The \velaboration of a deferred constant declaration has no other effect\v301.. The execution of a program is erroneous if it attempts to use the value of a deferred constant before the elaboration of the corresponding full declaration. Note: The full declaration for a deferred constant that has a given private type must not appear before the corresponding full type declaration. This is a consequence of the rules defining the allowed uses of a name that denotes a private type (see 7.4.1). 7.4.4 \uLimited Types\n A limited type is a type for which neither \vassignment\v502. nor the predefined comparison for \vequality\v413. and inequality is \vimplicitly declared\v301.. A \vprivate type declaration\704. that includes the reserved word limited declares a limited type. A \vtask type\v901. is a limited \vtype\v305.. A \vtype derived\v309. from a limited type is itself a limited type. Finally, a \vcomposite type\v305. is limited if the type of any of its \vsubcomponents\v305. is limited. The \voperations\v305. available for a private type that is limited are as given in section 7.4.2 for private types except for the absence of assignment and of a predefined comparison for equality and inequality. For a \vformal parameter\v601. whose type is limited and whose declaration occurs in an explicit \vsubprogram\v600. declaration, the \vmode\v1202. out is only allowed if this type is private and the subprogram declaration occurs within the visible part of the \vpackage\v700. that declares the private type. The same holds for formal parameters of entry declarations and of generic procedure declarations. The corresponding \vfull type\v705. must not be limited if the mode out is used for any such formal parameter. Otherwise, the corresponding full type is allowed (but not required) to be a limited type (in particular, it is allowed to be a task type). If the full type corresponding to a limited private type is not itself limited, then assignment for the type is available within the package, but not outside. The following are consequences of the rules for limited types: - An explicit initialization is not allowed in an \vobject declaration\v302. if the type of the object is limited. - A default expression is not allowed in a \vcomponent declaration\v325. if the type of the \vrecord component\v325. is limited. - An explicit \vinitial value\v303. is not allowed in an \vallocator\v421. if the \vdesignated\v330. type is limited. - A \vgeneric formal parameter\v1201. of mode in must not be of a limited type. \uNotes:\n The above rules do not exclude a default expression for a formal parameter of a limited type; they do not exclude a \vdeferred constant\v707. of a limited type if the full type is not limited. An explicit declaration of an equality operator is allowed for a limited type (see 6.7). \vAggregates\v407. are not available for a limited composite type (see 3.6.2 and 3.7.4). \vCatenation\v411. is not available for a limited array type (see 3.6.2). Example: \upackage\n I_O_\UPACKAGE\N is \utype\n FILE_NAME \uis limited private\n; \uprocedure\n OPEN (F : \uin out\n FILE_NAME); \uprocedure\n CLOSE(F : \uin out\n FILE_NAME); \uprocedure\n READ (F : \uin\n FILE_NAME; ITEM : \uout\n INTEGER); \uprocedure\n WRITE(F : \uin\n FILE_NAME; ITEM : \uin\n INTEGER); \uprivate\n \utype\n FILE_NAME \uis\n \urecord\n INTERNAL_NAME : INTEGER := 0; \uend record\n; \uend\n I_O_\UPACKAGE\N; \upackage body\n I_O_\UPACKAGE\N \uis\n LIMIT : \uconstant\n := 200; \utype\n FILE_DESCRIPTOR \uis record\n ... \uend record\n; DIRECTORY : \uarray\n (1 .. LIMIT) \uof\n FILE_DESCRIPTOR; ... \uprocedure\n OPEN (F : \uin out\n FILE_NAME) \uis\n ... \uend\n; \uprocedure\n CLOSE(F : \uin out\n FILE_NAME) \uis\n ... \uend\n; \uprocedure\n READ (F : \uin\n FILE_NAME; ITEM : \uout\n INTEGER) \uis\n ... \uend\n; \uprocedure\n WRITE(F : \uin\n FILE_NAME; ITEM : \uin\n INTEGER) \uis\n ... \uend\n; \ubegin\n ... \uend\n I_O_PACKAGE; Notes on the example: In the example above, an outside subprogram making use of I_O_PACKAGE may obtain a file name by calling OPEN and later use it in calls to READ and WRITE. Thus, outside the package, a file name obtained from OPEN acts as a kind of password; its internal properties (such as containing a numeric value) are not known and no other operations (such as addition or comparison of internal names) can be performed on a file name. This example is characteristic of any case where complete control over the operations of a type is desired. Such packages serve a dual purpose. They prevent a user from making use of the internal structure of the type. They also implement the notion of an encapsulated data type where the only operations on the type are those given in the package specification. 7.5 \uExample of a Table Management Package\n The following example illustrates the use of packages in providing high level procedures with a simple interface to the user. The problem is to define a table management package for inserting and retrieving items. The items are inserted into the table as they are supplied. Each inserted item has an order number. The items are retrieved according to their order number, where the item with the lowest order number is retrieved first. From the user's point of view, the package is quite simple. There is a type called ITEM designating table items, a procedure INSERT for inserting items, and a procedure RETRIEVE for obtaining the item with the lowest order number. There is a special item NULL_ITEM that is returned when the table is empty, and an exception TABLE_FULL which is raised by INSERT if the table is already full. A sketch of such a package is given below. Only the specification of the package is exposed to the user. \upackage\n TABLE_MANAGER \uis\n \utype\n ITEM \uis\n \urecord\n ORDER_NUM : INTEGER; ITEM_CODE : INTEGER; QUANTITY : INTEGER; ITEM_TYPE : CHARACTER; \uend record\n; NULL_ITEM : \uconstant\n ITEM := (ORDER_NUM | ITEM_CODE | QUANTITY => 0, ITEM_TYPE => ' '); \uprocedure\n INSERT (NEW_ITEM : \uin\n ITEM); \uprocedure\n RETRIEVE(FIRST_ITEM : \uout\n ITEM); TABLE_FULL : \uexception\n; -- raised by INSERT when table full \uend\n; The details of implementing such packages can be quite complex; in this case they involve a two-way linked table of internal items. A local housekeeping procedure EXCHANGE is used to move an internal item between the busy and the free lists. The initial table linkages are established by the initialization part. The package body need not be shown to the users of the package. \upackage body\n TABLE_MANAGER \uis\n SIZE : \uconstant\n := 2000; \usubtype\n INDEX \uis\n INTEGER \urange\n 0 .. SIZE; \utype\n INTERNAL_ITEM \uis\n \urecord\n CONTENT : ITEM; SUCC : INDEX; PRED : INDEX; \uend record\n; TABLE : \uarray\n (INDEX) \uof\n INTERNAL_ITEM; FIRST_BUSY_ITEM : INDEX := 0; FIRST_FREE_ITEM : INDEX := 1; \ufunction\n FREE_LIST_EMPTY \ureturn\n BOOLEAN \uis\n ... \uend\n; \ufunction\n BUSY_LIST_EMPTY \ureturn\n BOOLEAN \uis\n ... \uend\n; \uprocedure\n EXCHANGE (FROM : \uin\n INDEX; TO : \uin\n INDEX) \uis\n ... \uend\n; \uprocedure\n INSERT (NEW_ITEM : \uin\n ITEM) \uis\n \ubegin\n \uif\n FREE_LIST_EMPTY \uthen\n \uraise\n TABLE_FULL; \uend if\n; -- remaining code for INSERT \uend\n INSERT; \uprocedure\n RETRIEVE (FIRST_ITEM : \uout\n ITEM) \uis\n ... \uend\n; \ubegin\n -- initialization of the table linkages \uend\n TABLE_MANAGER; 7.6 \uExample of a Text Handling Package\n This example illustrates a simple text handling package. The users only have access to the visible part; the implementation is hidden from them in the private part and the package body (not shown). From a user's point of view, a TEXT is a variable-length string. Each text object has a maximum length, which must be given when the object is declared, and a current value, which is a string of some length between zero and the maximum. The maximum possible length of a text object is an implementation-defined constant. The package defines first the necessary types, then functions that return some characteristics of objects of the type, then the conversion functions between texts and the predefined CHARACTER and STRING types, and finally some of the standard operations on varying strings. Most operations are overloaded on strings and characters as well as on the type TEXT, in order to minimize the number of explicit conversions the user has to write. \upackage\n TEXT_HANDLER \uis\n MAXIMUM : \uconstant\n := SOME_VALUE; -- implementation-defined \usubtype\n INDEX \uis\n INTEGER \urange\n 0 .. MAXIMUM; \utype\n TEXT(MAXIMUM_LENGTH : INDEX) \uis limited private\n; \ufunction\n LENGTH (T : TEXT) \ureturn\n INDEX; \ufunction\n VALUE (T : TEXT) \ureturn\n STRING; \ufunction\n EMPTY (T : TEXT) \ureturn\n BOOLEAN; \ufunction\n TO_TEXT (S : STRING; MAX : INDEX) \ureturn\n TEXT; -- maximum length MAX \ufunction\n TO_TEXT (C : CHARACTER; MAX : INDEX) \ureturn\n TEXT; \ufunction\n TO_TEXT (S : STRING) \ureturn\n TEXT; -- maximum length S'LENGTH \ufunction\n TO_TEXT (C : CHARACTER) \ureturn\n TEXT; \ufunction\n "&" (LEFT : TEXT; RIGHT : TEXT) \ureturn\n TEXT; \ufunction\n "&" (LEFT : TEXT; RIGHT : STRING) \ureturn\n TEXT; \ufunction\n "&" (LEFT : STRING; RIGHT : TEXT) \ureturn\n TEXT; \ufunction\n "&" (LEFT : TEXT; RIGHT : CHARACTER) \ureturn\n TEXT; \ufunction\n "&" (LEFT : CHARACTER; RIGHT : TEXT) \ureturn\n TEXT; \ufunction\n "=" (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN; \ufunction\n "<" (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN; \ufunction\n "<=" (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN; \ufunction\n ">" (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN; \ufunction\n ">=" (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN; \uprocedure\n SET (OBJECT : \uin out\n TEXT; VALUE : \uin\n TEXT); \uprocedure\n SET (OBJECT : \uin out\n TEXT; VALUE : \uin\n STRING); \uprocedure\n SET (OBJECT : \uin out\n TEXT; VALUE : \uin\n CHARACTER); \uprocedure\n APPEND (TAIL : \uin\n TEXT; TO : \uin out\n TEXT); \uprocedure\n APPEND (TAIL : \uin\n STRING; TO : \uin out\n TEXT); \uprocedure\n APPEND (TAIL : \uin\n CHARACTER; TO : \uin out\n TEXT); \uprocedure\n AMEND (OBJECT : \uin out\n TEXT; BY : \uin\n TEXT; POSITION : \uin\n INDEX); \uprocedure\n AMEND (OBJECT : \uin out\n TEXT; BY : \uin\n STRING; POSITION : \uin\n INDEX); \uprocedure\n AMEND (OBJECT : \uin out\n TEXT; BY : \uin\n CHARACTER; POSITION : \uin\n INDEX); - amend replaces part of the object by the given text, string, or character - starting at the given position in the object \ufunction\n LOCATE (FRAGMENT : TEXT; WITHIN : TEXT) \ureturn\n INDEX; \ufunction\n LOCATE (FRAGMENT : STRING; WITHIN : TEXT) \ureturn\n INDEX; \ufunction\n LOCATE (FRAGMENT : CHARACTER; WITHIN : TEXT) \ureturn\n INDEX; -- all \ureturn\n 0 if the fragment is not located \uprivate\n \utype\n TEXT(MAXIMUM_LENGTH : INDEX) \uis\n \urecord\n POS : INDEX := 0; VALUE : STRING(1 .. MAXIMUM_LENGTH); \uend record\n; \uend\n TEXT_HANDLER; Example of use of the text handling package: A program opens an output file, whose name is supplied by the string NAME. This string has the form [DEVICE :] [FILENAME [.EXTENSION]] There are standard defaults for device, filename, and extension. The user-supplied name is passed to EXPAND_FILE_NAME as a parameter, and the result is the expanded version, with any necessary defaults added. \ufunction\n EXPAND_FILE_NAME (NAME : STRING) \ureturn\n STRING is \uuse\n TEXT_HANDLER; DEFAULT_DEVICE : \uconstant\n STRING := "SY:"; DEFAULT_FILE_NAME : \uconstant\n STRING := "RESULTS"; DEFAULT_EXTENSION : \uconstant\n STRING := ".DAT"; MAXIMUM_FILE_NAME_LENGTH : \uconstant\n INDEX := SOME_APPROPRIATE_VALUE; FILE_NAME : TEXT(MAXIMUM_FILE_NAME_LENGTH); \ubegin\n SET(FILE_NAME, NAME); \uif\n EMPTY(FILE_NAME) \uthen\n SET(FILE_NAME, DEFAULT_FILE_NAME); \uend if\n; \uif\n LOCATE(':', FILE_NAME) = 0 \uthen\n SET(FILE_NAME, DEFAULT_DEVICE & FILE_NAME); \uend if\n; \uif\n LOCATE('.', FILE_NAME) = 0 \uthen\n APPEND(DEFAULT_EXTENSION, TO => FILE_NAME); \uend if\n; \ureturn\n VALUE(FILE_NAME); \uend\n EXPAND_FILE_NAME; 8. \uVisibility Rules\n The rules defining the \vscope\v802. of \vdeclarations\v301. and the rules defining which \videntifiers\v203. are visible at various points in the text of the program are described in this chapter. The formulation of these rules uses the notion of a \vdeclarative region\v801.. More details: 8.1 \vDeclarative Region\v801. 8.2 \vScope of Declarations\v802. 8.3 \vVisibility\v803. 8.4 \vUse Clauses\v804. 8.5 \vRenaming Declarations\v805. 8.6 \vThe Package Standard\v806. 8.7 \vThe Context of Overload Resolution\v807. 8.1 Declarative Region A declarative region is a portion of the program text. A single declarative region is formed by the text of each of the following: - A subprogram \vdeclaration\v301., a \vpackage declaration\v701., a task declaration, or a \vgeneric declaration\v1201., together with the corresponding body, if any. If the body is a \vbody stub\v1004., the declarative region also includes the corresponding \vsubunit\v1004.. If the program unit has subunits, they are also included. - An \ventry declaration\v905. together with the corresponding accept statements. - A \vrecord type\v325. declaration, together with a corresponding private or \vincomplete type declaration\v331. if any, and together with a corresponding \vrecord representation clause\v1304. if any. - A \vrenaming declaration\v805. that includes a \vformal part\v601., or a \vgeneric\v1201. \vparameter declaration\v1201. that includes either a formal part or a \vdiscriminant part\v326.. - A \vblock statement\v507. or a \vloop statement\v506.. In each of the above cases, the declarative region is said to be associated with the corresponding declaration or statement. A declaration is said to occur immediately within a declarative region if this region is the innermost region that encloses the declaration, not counting the declarative region (if any) associated with the declaration itself. A declaration that occurs immediately within a declarative region is said to be local to the region. Declarations in outer (enclosing) regions are said to be global to an inner (enclosed) declarative region. A local entity is one declared by a local declaration; a global entity is one declared by a global declaration. Some of the above forms of declarative region include several disjoint parts (for example, other declarative items can be between the declaration of a \vpackage\v700. and its body). Each declarative region is nevertheless considered as a (logically) continuous portion of the program text. Hence if any rule defines a portion of text as the text that extends from some specific point of a declarative region to the end of this region, then this portion is the corresponding subset of the declarative region (for example it does not include intermediate declarative items between the two parts of a package). \uNotes:\n As defined in section 3.1, the term declaration includes basic declarations, \vimplicit declarations\v301., and those declarations that are part of \vbasic declarations\v301., for example, discriminant and \vparameter\v601. \vspecifications\v601.. It follows from the definition of a declarative region that a \vdiscriminant specification\v326. occurs immediately within the region associated with the enclosing record type declaration. Similarly, a parameter specification occurs immediately within the region associated with the enclosing \vsubprogram body\v603. or \vaccept statement\v905.. The \vpackage STANDARD\v806. forms a declarative region which encloses all \vlibrary\v701. \vunits\v701.: the implicit declaration of each library unit is assumed to occur immediately within this package (see sections 8.6 and 10.1.1). Declarative regions can be nested within other declarative regions. For example, subprograms, packages, \vtask units\v900., generic units, and block statements can be nested within each other, and can contain record type declarations, loop statements, and accept statements. 8.2 \uScope of Declarations\n For each form of \vdeclaration\v301., the language rules define a certain portion of the program text called the scope of the declaration. The scope of a declaration is also called the scope of any entity declared by the declaration. Furthermore, if the declaration associates some notation with a declared entity, this portion of the text is also called the scope of this notation (either an \videntifier\v203., a \vcharacter literal\v207., an \voperator\v601. \vsymbol\v601., or the notation for a \vbasic operation\v308.). Within the scope of an entity, and only there, there are places where it is legal to use the associated notation in order to refer to the declared entity. These places are defined by the rules of \vvisibility\v803. and \voverloading\v610.. The scope of a declaration that \voccurs immediately within\v801. a \vdeclarative\v801. \vregion\v801. \vextends\v801. from the beginning of the declaration to the end of the declarative region; this part of the scope of a declaration is called the immediate scope. Furthermore, for any of the declarations listed below, the scope of the declaration extends beyond the immediate scope: (a) A declaration that occurs immediately within the visible part of a \vpackage declaration\v701.. (b) An \ventry declaration\v905.. (c) A \vcomponent declaration\v325.. (d) A \vdiscriminant specification\v326.. (e) A \vparameter specification\v601.. (f) A \vgeneric parameter declaration\v1201.. In each of these cases, the given declaration occurs immediately within some enclosing declaration, and the scope of the given declaration extends to the end of the scope of the enclosing declaration. In the absence of a \vsubprogram declaration\v601., the subprogram specification given in the \vsubprogram body\v603. or in the \vbody stub\v1004. acts as the declaration and rule (e) applies also in such a case. Note: The above scope rules apply to all forms of declaration defined by section 3.1; in particular, they apply also to \vimplicit declarations\v301.. Rule (a) applies to a package declaration and thus not to the \vpackage specification\v701. of a \vgeneric declaration\v1201.. For nested declarations, the rules (a) through (f) apply at each level. For example, if a task unit is declared in the \vvisible part\v702. of a package, the scope of an entry of the \vtask unit\v900. extends to the end of the scope of the task unit, that is, to the end of the scope of the enclosing package. The scope of a \vuse clause\v804. is defined in section 8.3 \uVisibility\n The meaning of the occurrence of an \videntifier\v203. at a given place in the text is defined by the visibility rules and also, in the case of \voverloaded\v610. \vdeclarations\v301., by the overloading rules. The identifiers considered in this chapter include any identifier other than a \vreserved word\v211., an attribute designator, a \vpragma identifier\v210., the identifier of a pragma \vargument\v210., or an identifier given as a pragma argument. The places considered in this chapter are those where a \vlexical element\v202. (such as an identifier) occurs. The overloaded declarations considered in this chapter are those for \vsubprograms\v600., enumeration literals, and single entries. For each identifier and at each place in the text, the visibility rules determine a set of declarations (with this identifier) that define possible meanings of an occurrence of the identifier. A declaration is said to be \vvisible\v702. at a given place in the text when, according to the visibility rules, the declaration defines a possible meaning of this occurrence. Two cases arise. - The visibility rules determine at most one possible meaning. In such a case the visibility rules are sufficient to determine the declaration defining the meaning of the occurrence of the identifier, or in the absence of such a declaration, to determine that the occurrence is not legal at the given point. - The visibility rules determine more than one possible meaning. In such a case the occurrence of the identifier is legal at this point if and only if exactly one visible declaration is acceptable for the overloading rules in the given context (see section 6.6 for the rules of overloading and section 8.7 for the context used for overload resolution). A declaration is only visible within a certain part of its \vscope\v802.; this part starts at the end of the declaration except in a \vpackage\v700. specification, in which case it starts at the reserved word is given after the identifier of the package specification. (This rule applies, in particular, for \vimplicit declarations\v301..) Visibility is either by selection or direct. A declaration is visible by selection at places that are defined as follows. (a) For a declaration given in the visible part of a package declaration: at the place of the \vselector\v404. after the dot of an \vexpanded name\v404. whose prefix denotes the package. (b) For an \ventry declaration\v905. of a given \vtask type\v901.: at the place of the selector after the dot of a \vselected component\v404. whose prefix is appropriate for the task type. (c) For a \vcomponent declaration\v325. of a given record \vtype declaration\v305.: at the place of the selector after the dot of a \vselected component\v404. whose prefix is \vappropriate for the type\v401.; also at the place of a component simple name (before the \vcompound delimiter\v202. =>) in a named component association of an \vaggregate\v407. of the type. (d) For a \vdiscriminant specification\v326. of a given \vtype declaration\v306.: at the same places as for a component declaration; also at the place of a discriminant \vsimple name\v401. (before the compound delimiter =>) in a named discriminant association of a \vdiscriminant constraint\v327. for the type. (e) For a \vparameter specification\v601. of a given subprogram specification or entry declaration: at the place of the \vformal parameter\v601. (before the compound delimiter =>) in a named \vparameter association\v606. of a corresponding subprogram or \ventry call\v905.. (f) For a \vgeneric parameter declaration\v1201. of a given \vgeneric unit\v1200.: at the place of the \vgeneric formal parameter\v1201. (before the compound delimiter =>) in a named \vgeneric association\v1206. of a corresponding generic instantiation. Finally, within the \vdeclarative region\v801. associated with a construct other than a \vrecord type\v325. declaration, any declaration that \voccurs immediately\v801. \vwithin\v801. the region is visible by selection at the place of the selector after the dot of an expanded name whose prefix denotes the construct. Where it is not visible by selection, a visible declaration is said to be directly visible. A declaration is directly visible within a certain part of its \vimmediate scope\v802.; this part extends to the end of the immediate scope of the declaration, but excludes places where the declaration is hidden as explained below. In addition, a declaration occurring immediately within the visible part of a package can be made directly visible by means of a \vuse clause\v804. according to the rules described in section 8.4. (See also section 8.6 for the visibility of \vlibrary units\v1001..) A declaration is said to be hidden within (part of) an inner declarative region if the inner region contains a homograph of this declaration; the outer declaration is then hidden within the immediate scope of the inner homograph. Each of two declarations is said to be a homograph of the other if both declarations have the same identifier and overloading is allowed for at most one of the two. If overloading is allowed for both declarations, then each of the two is a homograph of the other if they have the same identifier, \voperator symbol\v601., or \vcharacter literal\v207., as well as the same \vparameter\v602. and \vresult type profile\v805. Within the specification of a subprogram, every declaration with the same designator as the subprogram is hidden; the same holds within a \vgeneric\v1206. \vinstantiation\v1206. that declares a subprogram, and within an entry declaration or the formal part of an \vaccept statement\v905.; where hidden in this manner, a declaration is visible neither by selection nor directly. Two declarations that occur immediately within the same declarative region must not be homographs, unless either or both of the following requirements are met: (a) exactly one of them is the implicit declaration of a predefined operation; (b) exactly one of them is the implicit declaration of a derived subprogram. In such cases, a predefined operation is always hidden by the other homograph; a derived subprogram hides a predefined operation, but is hidden by any other homograph. Where hidden in this manner, an implicit declaration is hidden within the entire scope of the other declaration (regardless of which declaration occurs first); the implicit declaration is visible neither by selection nor directly. Whenever a declaration with a certain identifier is visible from a given point, the identifier and the declared entity (if any) are also said to be visible from that point. Direct visibility and visibility by selection are likewise defined for character literals and operator symbols. An \voperator\v411. is directly visible if and only if the corresponding operator declaration is directly visible. Finally, the notation associated with a \vbasic\v308. \voperation\v308. is directly visible within the entire scope of this operation. Example: procedure P is A, B : BOOLEAN; procedure Q is C : BOOLEAN; B : BOOLEAN; -- an inner homograph of B begin B := A; -- means Q.B := P.A; C := P.B; -- means Q.C := P.B; begin A := B; -- means P.A := P.B; Note on the visibility of library units: The visibility of library units is determined by with clauses (see 10.1.1) and by the fact that library units are implicitly declared in the package STANDARD (see 8.6). Note on homographs: The same identifier may occur in different declarations and may thus be associated with different entities, even if the scopes of these declarations overlap. Overlap of the scopes of declarations with the same identifier can result from overloading of subprograms and of enumeration literals. Such overlaps can also occur for entities declared in package visible parts and for entries, record components, and parameters, where there is overlap of the scopes of the enclosing package declarations, task declarations, record type declarations, subprogram declarations, renaming declarations, or generic declarations. Finally overlapping scopes can result from nesting. Note on immediate scope, hiding, and visibility: The rules defining immediate scope, hiding, and visibility imply that a reference to an identifier within its own declaration is illegal (except for packages and \vgeneric packages\v1201. ). The identifier hides outer homographs within its immediate scope, that is, from the start of the declaration; on the other hand, the identifier is visible only after the end of the declaration. For this reason, all but the last of the following declarations are illegal: K : INTEGER := K * K; -- illegal T : T; -- illegal procedure P(X : P); -- illegal procedure Q(X : REAL := Q); -- illegal, even if there is a -- function named Q procedure R(R : REAL); -- an inner declaration is legal (although -- confusing) 8.4 \uUse Clauses\n A use clause achieves direct visibility of \vdeclarations\v301. that appear in the \vvisible parts\v702. of named \vpackages\v700.. use_clause ::= use package_name {, package_name}; For each use clause, there is a certain region of text called the \vscope\v802. of the use clause. This region starts immediately after the use clause. If a use clause is a \vdeclarative item\v333. of some \vdeclarative region\v801., the scope of the clause \vextends\v801. to the end of the declarative region. If a use clause occurs within a \vcontext clause\v1001. of a \vcompilation unit\v1001., the scope of the use clause extends to the end of the declarative region associated with the compilation unit. In order to define which declarations are made \vdirectly visible\v803. at a given place by use clauses, consider the set of packages named by all use clauses whose scopes enclose this place, omitting from this set any packages that enclose this place. A declaration that can be made directly visible by a use clause (a potentially visible declaration) is any declaration that \voccurs immediately within\v801. the visible part of a package of the set. A potentially visible declaration is actually made directly visible except in the following two cases: - A potentially visible declaration is not made directly visible if the place considered is within the \vimmediate scope\v802. of a \vhomograph\v803. of the declaration. - Potentially visible declarations that have the same \videntifier\v203. are not made directly visible unless each of them is either an \venumeration\v311. \vliteral specification\v311. or the declaration of a subprogram (by a \vsubprogram declaration\v601., a renaming declaration, a generic instantiation, or an implicit declaration). The \velaboration\v301. of a use clause has no other effect. Note: The above rules guarantee that a declaration that is made directly visible by a use clause cannot hide an otherwise directly visible declaration. The above rules are formulated in terms of the set of packages named by use clauses. Consequently, the following lines of text all have the same effect (assuming only one package P). use P; use P; use P, P; Example of conflicting names in two packages: procedure R is package TRAFFIC is type COLOR is (RED, AMBER, GREEN); end TRAFFIC; package WATER_COLORS is type COLOR is (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK); end WATER_COLORS; use TRAFFIC; -- COLOR, RED, AMBER, and GREEN are directly visible use WATER_COLORS; -- two homographs of GREEN are directly visible -- but COLOR is no longer directly visible subtype LIGHT is TRAFFIC.COLOR; --Subtypes are used to resolve subtype SHADE is WATER_COLORS.COLOR; --the conflicting type name COLOR SIGNAL : LIGHT; PAINT : SHADE; begin SIGNAL := GREEN; -- that of TRAFFIC PAINT := GREEN; -- that of WATER_COLORS end R; Example of \vname\v401. identification with a use clause: package D is T, U, V : BOOLEAN; end D; procedure P is package E is B, W, V : INTEGER; end E; procedure Q is T, X : REAL; use D, E; begin -- the name T means Q.T, not D.T -- the name U means D.U -- the name B means E.B -- the name W means E.W -- the name X means Q.X -- the name V is illegal : either D.V or E.V must be used end Q; begin end P; 8.5 \uRenaming Declarations\n A renaming \vdeclaration\v301. declares another \vname\v401. for an entity. renaming_declaration ::= identifier : type_mark renames object_name; | identifier : exception renames exception_name; | \vpackage\v700. identifier renames package_name; | subprogram_specification renames subprogram_or_entry_name; The \velaboration\v301. of a renaming declaration evaluates the name that follows the \vreserved word\v211. renames and thereby determines the entity denoted by this name (the renamed entity). At any point where a renaming declaration is visible, the identifier, or \voperator symbol\v601. of this declaration denotes the renamed entity. The first form of renaming declaration is used for the renaming of \vobjects\v302.. The renamed entity must be an object of the \vbase type\v305. of the \vtype mark\v305.. The properties of the renamed object are not affected by the renaming declaration. In particular, its value and whether or not it is a \vconstant\v303. are unaffected; similarly, the \vconstraints\v305. that apply to an object are not affected by renaming (any constraint implied by the type mark of the renaming declaration is ignored). The renaming declaration is \vlegal\v108. only if exactly one object has this type and can be denoted by the object name. The following restrictions apply to the renaming of a \vsubcomponent\v305. that \vdepends on discriminants\v326. of a \vvariable\v303.. The renaming is not allowed if the \vsubtype\v307. of the variable, as defined in a corresponding \vobject declaration\v302., component declaration, or component subtype indication, is an unconstrained type; or if the variable is a generic formal object (of \vmode\v601. in out). Similarly if the variable is a \vformal parameter\v601., the renaming is not allowed if the type mark given in the \vparameter specification\v601. denotes an nconstrained type whose \vdiscriminants\v326. have \vdefault expressions\v601.. The second form of renaming declaration is used for the renaming of exceptions; the third form, for the renaming of packages. The last form of renaming declaration is used for the renaming of \vsubprograms\v600. and entries. The renamed subprogram or \ventry\v905. and the subprogram specification given in the renaming declaration must have the same \vparameter\v602. and result type profile (see 6.6). The renaming declaration is legal only if exactly one visible subprogram or entry satisfies the above requirements and can be denoted by the given subprogram or entry name. In addition, parameter modes must be identical for formal parameters that are at the same parameter position. The subtypes of the parameters and result (if any) of a renamed subprogram or entry are not affected by renaming. These subtypes are those given in the original \vsubprogram declaration\v601., generic instantiation, or entry declaration (not those of the renaming declaration); even for calls that use the new name. On the other hand, a renaming declaration can introduce parameter names and default expressions that differ from those of the renamed subprogram; named associations of calls with the new subprogram name must use the new parameter name; calls with the old subprogram name must use the old parameter names. A \vprocedure\v601. can only be renamed as a procedure. Either of a \vfunction\v609. or \voperator\v611. can be renamed as either of a function or operator; for renaming as an operator, the \vsubprogram specification\v601. given in the renaming declaration is subject to the rules given in section 6.7 for \voperator\v611. \vdeclarations\v611.. \vEnumeration literals\v311. can be renamed as functions; similarly, attributes defined as functions (such as SUCC and PRED) can be renamed as functions. An entry can only be renamed as a procedure; the new name is only allowed to appear in contexts that \vallow\v108. a procedure name. An \ventry of a family\v905. can be renamed, but an entry family cannot be renamed as a whole. \uExamples:\n declare L : PERSON renames LEFTMOST_PERSON; -- see 3.8.1 begin L.AGE := L.AGE + 1; FULL : \vexception\v1100. renames TABLE_MANAGER.TABLE_FULL; -- see 7.5 package TM renames TABLE_MANAGER; function REAL_PLUS(LEFT, RIGHT : REAL ) return REAL renames "+"; function INT_PLUS (LEFT, RIGHT : INTEGER) return INTEGER renames "+"; function ROUGE return COLOR renames RED; -- see 3.5.1 function ROT return COLOR renames RED; function ROSSO return COLOR renames ROUGE; function NEXT(X : COLOR) return COLOR renames COLOR'SUCC; -- see 3.5.5 Example of a renaming declaration with new parameter names: function "*" (X,Y : VECTOR) return REAL renames DOT_PRODUCT; -- see 6.1 Example of a renaming declaration with a new default expression: function MINIMUM(L : LINK := HEAD) return CELL renames MIN_CELL; -- see 6.1 \uNotes:\n Renaming may be used to resolve name conflicts and to act as a shorthand. Renaming with a different \videntifier\v203. or operator symbol does not hide the old name; the new name and the old name need not be \vvisible\v803. at the same points. The attributes POS and VAL cannot be renamed since the corresponding specifications cannot be written; the same holds for the predefined multiplying operators with a universal_fixed result. Calls with the new name of a renamed entry are \vprocedure call statements\v606. and are not allowed at places where the syntax requires an \ventry call\v905. \vstatement\v905. in \vconditional and timed entry calls\v909.; similarly, the COUNT \vattribute\v405. is not available for the new name. A \vtask object\v902. that is declared by an object declaration can be renamed as an object. However, a single task cannot be renamed since the corresponding task type is anonymous. For similar reasons, an object of an anonymous array type cannot be renamed. No syntactic form exists for renaming a generic unit. A subtype can be used to achieve the effect of renaming a type (including a task type) as in subtype MODE is TEXT_IO.FILE_MODE; 8.6 \uThe Package Standard\n The predefined \vtypes\v305. (for example the types BOOLEAN, CHARACTER and INTEGER) are the types that are declared in a predefined \vpackage\v700. called STANDARD; this package also includes the \vdeclarations\v301. of their predefined operations. The package STANDARD is described in Annex C. Apart from the predefined numeric types, the specification of the package STANDARD \vmust\v108. be the same for all implementations of the language. The package STANDARD forms a \vdeclarative region\v801. which encloses every \vlibrary unit\v1001. and consequently the \vmain program\v1001.; the declaration of every library unit is assumed to \voccur immediately within\v801. this package. The \vimplicit declarations\v301. of library units are assumed to be ordered in such a way that the scope of a given library unit includes any compilation unit that mentions the given library unit in a \vwith clause\v1002.. However, the only library units that are visible within a given compilation unit are as follows: they include the library units \vnamed\v401. by all with clauses that apply to the given unit, and moreover, if the given unit is a \vsecondary\v1001. \vunit\v1001. of some library unit, they include this library unit. \uNotes:\n If all \vblock statements\v507. of a program are named, then the name of each \vprogram unit\v600. can always be written as an \vexpanded name\v404. starting with STANDARD (unless this package is itself hidden). If a type is declared in the visible part of a library package, then it is a consequence of the \vvisibility\v803. rules that a basic operation (such as \vassignment\v502.) for this type is directly visible at places where the type itself is not visible (whether by selection or directly). However this operation can only be applied to operands that are visible and the declaration of these operands requires the visibility of either the type or one of its \vsubtypes\v305.. 8.7 \uThe Context of Overload Resolution\n \vOverloading\v610. is defined for \vsubprograms\v600., \venumeration literals\v311., \voperators\v411., and single entries, and also for the \voperations\v308. that are inherent in several \vbasic operations\v308. such as \vassignment\v502., \vmembership tests\v413., \vallocators\v421., the \vliteral null\v330., \vaggregates\v407., and \vstring literals\v406.. For overloaded entities, overload resolution determines the actual meaning that an occurrence of an \videntifier\v203. has, whenever the \vvisibility\v803. rules have determined that more than one meaning is acceptable at the place of this occurrence; overload resolution likewise determines the actual meaning of an occurrence of an operator or some basic operation. At such a place all visible \vdeclarations\v301. are considered. The occurrence is only \vlegal\v108. if there is exactly one interpretation of each constituent of the innermost complete context; a complete context is one of the following: - A declaration. - A \vstatement\v500.. - A \vrepresentation clause\v1301.. When considering possible interpretations of a complete context, the only rules considered are the syntax rules, the scope and visibility rules, and the rules of the form described below. (a) Any rule that requires a \vname\v401. or \vexpression\v410. to have a certain type, or to have the same type as another name or expression. (b) Any rule that requires the type of a name or expression to be a type of a certain class; similarly, any rule that requires a certain type to be a discrete, integer, real, universal, character, boolean, or nonlimited type. (c) Any rule that requires a prefix to be appropriate for a certain type. (d) Any rule that specifies a certain type as the result type of a basic operation, and any rule that specifies that this type is of a certain class. (e) The rules that require the type of an aggregate or string \vliteral\v406. to be determinable solely from the enclosing complete context (see 4.3 and 4.2). Similarly, the rules that require the type of the prefix of an attribute, the type of the expression of a \vcase statement\v505., or the type of the operand of a \vtype conversion\v419., to be determinable independently of the context (see 4.1.4, 5.4, 4.6, and 6.4.1). (f) The rules given in section 6.6, for the resolution of overloaded subprogram calls; in section 4.6, for the implicit conversions of universal expressions; in section 3.6.1, for the interpretation of \vdiscrete ranges\v322. with bounds having a universal type; and in section 4.1.3, for the interpretation of an expanded name whose prefix denotes a subprogram or an accept statement. Subprogram names used as \vpragma\v210. arguments follow a different rule: the pragma can apply to several overloaded subprograms, as explained in section 6.3.2 for the pragma INLINE, in section 11.7 for the pragma SUPPRESS, and in section 13.9 for the pragma INTERFACE. Similarly, the simple names given in context clauses (see 10.1.1) and in \vaddress clauses\v1305. follow different rules. \uNotes:\n If there is only one possible interpretation, the identifier denotes the corresponding entity. However, this does not mean that the occurrence is necessarily legal since other requirements exist which are not considered for overload resolution; for example, the fact that an expression is \vstatic\v422., the parameter modes, whether an object is constant, \vconformance\v905. \vrules\v905., forcing occurrences for a representation clause, order of elaboration, and so on. Similarly, \vsubtypes\v305. are not considered for overload resolution (the violation of a constraint does not make a program illegal but raises an \vexception\v1100. during program execution). A \vloop parameter specification\v506. is a declaration, and hence a complete context. Rules that require certain constructs to have the same parameter and result type profile fall under the category (a); the same holds for rules that require conformance of two constructs since conformance requires that corresponding names be given the same meaning by the visibility and overloading rules. 9. \uTasks\n The execution of a program that does not contain a task is defined in terms of a sequential execution of its actions, according to the rules described in other chapters of this manual. These actions can be considered to be executed by a single logical processor. Tasks are entities whose executions proceed in parallel in the following sense. Each task can be considered to be executed by a logical processor of its own. Different tasks (different logical processors) proceed independently, except at points where they synchronize. Some tasks have entries. An \ventry\v905. of a task can be called by other tasks. A task accepts a call of one of its entries by executing an \vaccept\v905. \vstatement\v905. for the entry. Synchronization is achieved by \vrendezvous\v905. between a task issuing an entry call and a task accepting the call. Some entries have parameters; entry calls and accept statements for such entries are the principal means of communicating values between tasks. The properties of each task are defined by a corresponding task unit which consists of a \vtask specification\v901. and a \vtask body\v901.. Task units are one of the four forms of \vprogram unit\v600. of which programs can be composed. The other forms are \vsubprograms\v600., \vpackages\v700. and \vgeneric units\v1200.. The properties of task units, tasks, and entries, and the statements that affect the interaction between tasks (that is, \ventry call statements\v905., accept statements, \vdelay statements\v906., \vselect statements\v907., and \vabort statements\v913.) are described in this chapter. Note: Parallel tasks (parallel logical processors) may be implemented on multicomputers, multiprocessors, or with interleaved execution on a single physical processor. On the other hand, whenever an implementation can detect that the same effect can be guaranteed if parts of the actions of a given task are executed by different physical processors acting in parallel, it may choose to execute them in this way; in such a case, several physical processors implement a single logical processor. More details: 9.1 \vTask Specifications and Task Bodies\v901. 9.2 \vTask Types and Task Objects\v902. 9.3 \vTask Execution - Task Activation\v903. 9.4 \vTask Dependence - Termination of Tasks\v904. 9.5 \vEntries, Entry Calls and Accept Statements\v905. 9.6 \vDelay Statements, Duration and Time\v906. 9.7 \vSelect Statements\v907. 9.8 \vPriorities\v911. 9.9 \vTask and Entry Attributes\v912. 9.10 \vAbort Statements\v913. 9.11 \vShared Variables\v914. 9.12 \vExample of Tasking\v915. 9.1 \uTask Specifications and Task Bodies\n A task unit consists of a task specification and a task body. A task specification that starts with the \vreserved words\v211. task \vtype\v305. declares a task type. The value of an \vobject\v302. of a task type designates a task having the entries, if any, that are declared in the task specification; these entries are also called entries of this object. The execution of the task is defined by the corresponding task body. A task specification without the reserved word type defines a single task. A task declaration with this form of specification is equivalent to the \vdeclaration\v301. of an anonymous task type immediately followed by the \vdeclaration of an object\v303. of the task type, and the task unit \videntifier\v203. names the object. In the remainder of this chapter, explanations are given in terms of task \vtype declarations\v306.; the corresponding explanations for single task declarations follow from the stated equivalence. task_declaration ::= task_specification; task_specification ::= task [type] identifier [is {\ventry_declaration\v905.} {\vrepresentation_clause\v1301.} end [task_simple_name]] task_body ::= task body task_simple_name is [\vdeclarative_part\v333.] begin sequence_of_statements [exception exception_handler {exception_handler}] end [task_simple_name]; The \vsimple name\v401. at the start of a task body must repeat the task unit identifier. Similarly if a simple name appears at the end of the task specification or body, it must repeat the task unit identifier. Within a task body, the name of the corresponding task unit can also be used to refer to the task object that designates the task currently executing the body; furthermore, the use of this name as a type mark is not allowed within the task unit itself. For the \velaboration\v333. of a task specification, \ventry\v905. declarations and representation clauses, if any, are elaborated in the order given. Such representation clauses only apply to the entries declared in the task specification (see 13.5). The elaboration of a task body has no other effect than to establish that the body can from then on be used for the execution of tasks designated by objects of the corresponding task type. The execution of a task body is invoked by the activation of a task object of the corresponding type (see 9.3). The optional \vexception handlers\v1102. at the end of a task body handle exceptions raised during the execution of the \vsequence of statements\v501. of the task body (see 11.4). Examples of specifications of task types: task type RESOURCE is entry SEIZE; entry RELEASE; end RESOURCE; task type KEYBOARD_DRIVER is entry READ (C : out CHARACTER); entry WRITE(C : in CHARACTER); end KEYBOARD_DRIVER; Examples of specifications of single tasks: task PRODUCER_CONSUMER is entry READ (V : out ITEM); entry WRITE(E : in ITEM); end; task CONTROLLER is entry REQUEST(LEVEL)(D : ITEM); -- a family of entries end CONTROLLER; task USER; -- has no entries Example of task specification and corresponding body: task PROTECTED_ARRAY is -- INDEX and ITEM are global types entry READ (N : in INDEX; V : out ITEM); entry WRITE(N : in INDEX; E : in ITEM); end; task body PROTECTED_ARRAY is TABLE : \uarray\n(INDEX) of ITEM := (INDEX => NULL_ITEM); begin loop select \uaccept\n READ (N : in INDEX; V : out ITEM) do V := TABLE(N); end READ; or \uaccept\n WRITE(N : in INDEX; E : in ITEM) do TABLE(N) := E; end WRITE; end select; end loop; end PROTECTED_ARRAY; Note: A task specification specifies the interface of tasks of the task type with other tasks of the same or of different types, and also with the \vmain\v1001. \vprogram\v1001.. 9.2 \uTask Types and Task Objects\n A task type is a \vlimited type\v708.. Hence neither \vassignment\v502. nor the predefined comparison for \vequality\v413. and \vinequality\v413. are defined for \vobjects\v302. of task types; moreover, the mode out is not allowed for a \vformal\v602. \vparameter\v602. whose \vtype\v305. is a task type. A task object is an object whose type is a task type. The value of a task object \vdesignates\v330. a task that has the entries of the corresponding task type, and whose execution is specified by the corresponding \vtask body\v901.. If a task object is the object, or a \vsubcomponent\v305. of the object, declared by an \vobject declaration\v303., then the value of the task object is defined by the \velaboration\v333. of the object declaration. If a task object is the object, or a subcomponent of the object, created by the evaluation of an \vallocator\v421., then the value of the task object is defined by the evaluation of the allocator. For all parameter modes, if an \vactual parameter\v607. designates a task, the associated formal parameter designates the same task; the same holds for a subcomponent of an actual parameter and the corresponding subcomponent of the associated formal parameter; finally, the same holds for generic parameters. \uExamples:\n CONTROL : RESOURCE; TELETYPE : KEYBOARD_DRIVER; POOL : \uarray\n(1 .. 10) of KEYBOARD_DRIVER; -- see also examples of declarations of single tasks in 9.1 Example of \vaccess type\v330. designating task objects: type KEYBOARD is \uaccess\n KEYBOARD_DRIVER; TERMINAL : KEYBOARD := new KEYBOARD_DRIVER; \uNotes:\n Since a task type is a limited type, it can appear as the definition of a limited \vprivate type\v704. in a \vprivate part\v702., and as a \vgeneric actual parameter\v1206. associated with a formal parameter whose type is a limited type. On the other hand, the type of a \vgeneric formal parameter of mode\v1202. in must not be a limited type and hence cannot be a task type. Task objects behave as \vconstants\v303. (a task object always designates the same task) since their values are implicitly defined either at declaration or allocation, or by a \vparameter association\v606., and since no assignment is available. However the \vreserved word\v211. constant is not allowed in the declaration of a task object since this would require an explicit \vinitialization\v303.. A task object that is a formal parameter of mode in is a constant (as is any formal parameter of this mode). If an application needs to store and exchange task identities, it can do so by defining an access type designating the corresponding task objects and by using access values for identification purposes (see above example). Assignment is available for such an access type as for any access type. \vSubtype declarations\v307. are allowed for task types as for other types, but there are no \vconstraints\v305. applicable to task types. 9.3 \uTask Execution - Task Activation\n A \vtask body\v901. defines the execution of any task that is designated by a \vtask\v902. \vobject\v902. of the corresponding \vtask type\v901.. The initial part of this execution is called the activation of the task object, and also that of the designated task; it consists of the \velaboration\v333. of the \vdeclarative part\v333., if any, of the task body. The execution of different tasks, in particular their activation, proceeds in \vparallel\v900.. If an object declaration that declares a task object occurs immediately within a declarative part, then the activation of the task object starts after the elaboration of the declarative part (that is, after passing the reserved word begin following the declarative part); similarly if such a declaration occurs immediately within a package specification, the activation starts after the elaboration of the declarative part of the \vpackage body\v701.. The same holds for the activation of a task object that is a \vsubcomponent\v305. of an object declared immediately within a declarative part or package specification. The first \vstatement\v500. following the declarative part is executed only after conclusion of the activation of these task objects. Should an \vexception\v1100. be raised by the activation of one of these tasks, that task becomes a \vcompleted task\v904.; other tasks are not directly affected. Should one of these tasks thus become completed during its activation, the \vexception TASKING_ERROR\v1101. is raised upon conclusion of the activation of all of these tasks (whether successfully or not); the exception is raised at a place that is immediately before the first statement following the declarative part (immediately after the reserved word begin). Should several of these tasks thus become completed during their activation, the exception TASKING_ERROR is raised only once. Should an exception be raised by the elaboration of a declarative part or package specification, then any task that is created (directly or indirectly) by this elaboration and that is not yet activated becomes terminated and is therefore never activated (see section 9.4 for the definition of a terminated task). For the above rules, in any package body without statements, a null statement is assumed. For any package without a package body, an implicit package body containing a single null statement is assumed. If a package without a package body is declared immediately within some program unit or block statement, the implicit package body occurs at the end of the declarative part of the program unit or block statement; if there are several such packages, the order of the implicit package bodies is undefined. A task object that is the object, or a subcomponent of the object, created by the evaluation of an \vallocator\v421. is activated by this evaluation. The activation starts after any initialization for the object created by the allocator; if several subcomponents are task objects, they are activated in parallel. The access value designating such an object is returned by the allocator only after the conclusion of these activations. Should an exception be raised by the activation of one of these tasks, that task becomes a completed task; other tasks are not directly affected. Should one of these tasks thus become completed during its activation, the exception TASKING_ERROR is raised upon conclusion of the activation of all of these tasks (whether successfully or not); the exception is raised at the place where the allocator is evaluated. Should several of these tasks thus become completed during their activation, the exception TASKING_ERROR is raised only once. Should an exception be raised by the initialization of the object created by an allocator (hence before the start of any activation), any task designated by a subcomponent of this object becomes terminated and is therefore never activated. Example: procedure P is A, B : RESOURCE; -- elaborate the task objects A, B C : RESOURCE; -- elaborate the task object C begin -- the tasks A, B, C are activated in parallel before the first statement ... end; \uNotes:\n An \ventry\v905. of a task can be called before the task has been activated. If several tasks are activated in parallel, the execution of any of these tasks need not await the end of the activation of the other tasks. A task may become completed during its activation either because of an exception or because it is aborted (see 9.10). 9.4 \uTask Dependence - Termination of Tasks\n Each task depends on at least one master. A master is a construct that is either a task, a currently executing \vblock statement\v507. or subprogram, or a library package (a \vpackage\v700. declared within another \vprogram unit\v600. is not a master). The dependence on a master is a direct dependence in the following two cases: (a) The task designated by a \vtask object\v902. that is the \vobject\v302., or a \vsubcomponent\v305. of the object, created by the evaluation of an \vallocator\v421. depends on the master that elaborates the corresponding \vaccess type\v330. definition. (b) The task designated by any other task object depends on the master whose execution creates the task object. Furthermore, if a task depends on a given master that is a block \vstatement\v500. executed by another master, then the task depends also on this other master, in an indirect manner; the same holds if the given master is a subprogram called by another master, and if the given master is a task that depends (directly or indirectly) on another master. Dependences exist for objects of a private type whose full \vdeclaration\v301. is in terms of a task type. A task is said to have completed its execution when it has finished the execution of the \vsequence of statements\v501. that appears after the reserved word begin in the corresponding body. Similarly a block or a subprogram is said to have completed its execution when it has finished the execution of the corresponding sequence of statements. For a block statement, the execution is also said to be completed when it reaches an \vexit\v508., return, or \vgoto statement\v510. transferring control out of the block. For a procedure, the execution is also said to be completed when a corresponding \vreturn\v509. \vstatement\v509. is reached. For a \vfunction\v609., the execution is also said to be completed after the evaluation of the result expression of a return statement. Finally the execution of a task, block statement, or subprogram is completed if an \vexception\v1100. is raised by the execution of its sequence of statements and there is no corresponding \vhandler\v1102., or, if there is one, when it has finished the execution of the corresponding handler. If a task has no dependent task, its termination takes place when it has completed its execution. After its termination, a task is said to be terminated. If a task has dependent tasks, its termination takes place when the execution of the task is completed and all dependent tasks are terminated. A block statement or \vsubprogram body\v603. whose execution is completed is not left until all of its dependent tasks are terminated. Termination of a task otherwise takes place if and only if its execution has reached an \vopen terminate alternative\v908. in a select statement (see 9.7.1), and the following conditions are satisfied: - The task depends on some master whose execution is completed (hence not a library package). - Each task that depends on the master considered is either already terminated or similarly waiting on an open \vterminate alternative\v908. of a select statement. When both conditions are satisfied, the task considered becomes terminated, together with all tasks that depend on the master considered. Example: declare type GLOBAL is \uaccess\n RESOURCE; -- see 9.1 A, B : RESOURCE; G : GLOBAL; begin -- activation of A and B declare type LOCAL is \uaccess\n RESOURCE; X : GLOBAL := new RESOURCE; -- activation of X.\uall\n L : LOCAL := new RESOURCE; -- activation of L.\uall\n C : RESOURCE; begin -- activation of C G := X; -- both G and X \vdesignate\v330. the same task object ... end; -- await termination of C and L.\uall\n (but not X.\uall\n) ... end; -- await termination of A, B, and G.\uall\n \uNotes:\n The rules given for termination imply that all tasks that depend (directly or indirectly) on a given master and that are not already terminated, can be terminated (collectively) if and only if each of them is waiting on an open terminate alternative of a select statement and the execution of the given master is completed. The usual rules apply to the \vmain program\v1001.. Consequently, termination of the main program awaits termination of any dependent task even if the corresponding task type is declared in a library package. On the other hand, termination of the main program does not await termination of tasks that depend on library packages; the language does not define whether such tasks are required to terminate. For an access type derived from another access type, the corresponding access type definition is that of the parent type; the dependence is on the master that elaborates the ultimate parent access type definition. A \vrenaming declaration\v805. defines a new name for an existing entity and hence creates no further dependence. 9.5 \uEntries, Entry Calls, and Accept Statements\n Entry calls and accept statements are the primary means of synchronization of \vtasks\v900., and of communicating values between tasks. An entry declaration is similar to a \vsubprogram declaration\v601. and is only allowed in a \vtask\v901. \vspecification\v901.. The actions to be performed when an entry is called are specified by corresponding accept statements. entry_declaration ::= entry identifier [(discrete_range)] [formal_part]; entry_call_statement ::= entry_name [\vactual_parameter_part\v606.]; accept_statement ::= \uaccept\n entry_simple_name [(entry_index)] [formal_part] [do sequence_of_statements end [entry_simple_name]]; entry_index ::= \vexpression\v410. An entry declaration that includes a \vdiscrete range\v322. declares a family of distinct entries having the same \vformal part\v601. (if any); that is, one such entry for each value of the discrete range. The term single entry is used in the definition of any rule that applies to any entry other than one of a family. The task designated by an \vobject\v302. of a task type has (or owns) the entries declared in the specification of the task type. Within the body of a task, each of its single entries or entry families can be named by the corresponding \vsimple name\v401.. The \vname\v401. of an entry of a family takes the form of an \vindexed component\v402., the family simple name being followed by the index in parentheses; the type of this index must be the same as that of the discrete range in the corresponding entry family declaration. Outside the body of a task an entry name has the form of a \vselected component\v404., whose \vprefix\v401. denotes the task object, and whose \vselector\v404. is the simple name of one of its single entries or entry families. A single entry overloads a \vsubprogram\v600., an \venumeration literal\v311., or another single entry if they have the same \videntifier\v203.. \vOverloading\v610. is not defined for entry families. A single entry or an entry of an entry family can be renamed as a \vprocedure\v600. as explained in section 8.5. The parameter modes defined for parameters of the formal part of an entry declaration are the same as for a subprogram declaration and have the same meaning (see 6.2). The syntax of an entry call statement is similar to that of a \vprocedure call\v606. statement, and the rules for parameter associations are the same as for subprogram calls (see 6.4.1 and 6.4.2). An accept statement specifies the actions to be performed at a call of a named entry (it can be an entry of a family). The formal part of an accept statement must conform to the formal part given in the declaration of the single entry or entry family named by the accept statement (see section 6.3.1 for the \vconformance rules\v604.). If a simple name appears at the end of an accept statement, it must repeat that given at the start. An accept statement for an entry of a given task is only allowed within the corresponding \vtask body\v901.; excluding within the body of any program unit that is, itself, inner to the task body; and excluding within another accept statement for either the same single entry or an entry of the same family. (One consequence of this rule is that a task can execute accept statements only for its own entries.) A task body can contain more than one accept statement for the same entry. For the \velaboration\v301. of an entry declaration, the discrete range, if any, is evaluated and the formal part, if any, is then elaborated as for a subprogram declaration. Execution of an accept statement starts with the \vevaluation\v411. of the entry index (in the case of an entry of a family). Execution of an entry call statement starts with the evaluation of the entry name; this is followed by any evaluations required for actual parameters in the same manner as for a subprogram call (see 6.4). Further execution of an accept statement and of a corresponding entry call statement are synchronized. If a given entry is called by only one task, there are two possibilities: - If the calling task issues an entry call statement before a corresponding accept statement is reached by the task owning the entry, the execution of the calling task is suspended. - If a task reaches an accept statement prior to any call of that entry, the execution of the task is suspended until such a call is received. When an entry has been called and a corresponding accept statement has been reached, the \vsequence of statements\v501., if any, of the accept statement is executed by the called task (while the calling task remains suspended). This interaction is called a rendezvous. Thereafter, the calling task and the task owning the entry continue their \vexecution in parallel\v900.. If several tasks call the same entry before a corresponding accept statement is reached, the calls are queued; there is one queue associated with each entry. Each execution of an accept statement removes one call from the queue. The calls are processed in the order of arrival. An attempt to call an entry of a task that has completed its execution raises the \vexception TASKING_ERROR\v1101. at the point of the call, in the calling task; similarly, this exception is raised at the point of the call if the called \vtask completes\v904. its execution before accepting the call (see also 9.10 for the case when the called \vtask becomes abnormal\v913.). The \vexception\v1101. \vCONSTRAINT_ERROR\v1101. is raised if the index of an entry of a family is not within the specified discrete range. Examples of entry declarations: entry READ(V : out ITEM); entry SEIZE; entry REQUEST(LEVEL)(D : ITEM); -- a family of entries Examples of entry calls: CONTROL.RELEASE; -- see 9.2 and 9.1 PRODUCER_CONSUMER.WRITE(E); -- see 9.1 POOL(5).READ(NEXT_CHAR); -- see 9.2 and 9.1 CONTROLLER.REQUEST(LOW)(SOME_ITEM); -- see 9.1 Examples of accept statements: \uaccept\n SEIZE; \uaccept\n READ(V : out ITEM) do V := LOCAL_ITEM; end READ; \uaccept\n REQUEST(LOW)(D : ITEM) do ... end REQUEST; \uNotes:\n The formal part given in an accept statement is not elaborated; it is only used to identify the corresponding entry. An accept statement can call subprograms that issue entry calls. An accept statement need not have a sequence of statements even if the corresponding entry has parameters. Equally, it can have a sequence of statements even if the corresponding entry has no parameters. The sequence of statements of an accept statement can include \vreturn statements\v509.. A task can call its own entries but it will, of course, deadlock. The language permits \vconditional\v909. and \vtimed entry calls\v910.. The language rules ensure that a task can only be in one entry queue at a given time. If the bounds of the discrete range of an entry family are integer literals, the index (in an entry name or accept statement) must be of the predefined \vtype INTEGER\v314. (see 3.6.1). 9.6 \uDelay Statements, Duration, and Time\n The execution of a delay \vstatement\v500. evaluates the \vsimple expression\v410., and suspends further execution of the \vtask\v900. that executes the delay statement, for at least the duration specified by the resulting value. delay_statement ::= delay simple_expression; The simple expression must be of the predefined \vfixed point type\v319. DURATION; its value is expressed in seconds; a delay statement with a negative value is equivalent to a delay statement with a zero value. Any implementation of the type \vDURATION\v1700. must allow representation of durations (both positive and negative) up to at least 86400 seconds (one day); the smallest representable duration, DURATION'SMALL must not be greater than twenty milliseconds (whenever possible, a value not greater than fifty microseconds should be chosen). Note that DURATION'SMALL need not correspond to the basic clock cycle, the named number SYSTEM.TICK (see 13.7). The definition of the \vtype\v305. TIME is provided in the predefined \vlibrary\v1001. \vpackage\v700. CALENDAR. The function CLOCK returns the current value of TIME at the time it is called. The functions YEAR, MONTH, DAY and SECONDS return the corresponding values for a given value of the type TIME; the procedure SPLIT returns all four corresponding values. Conversely, the function TIME_OF combines a year number, a month number, a day number, and a duration, into a value of type TIME. The \voperators\v411. "+" and "-" for \vaddition\v411. and subtraction of times and durations, and the \vrelational\v411. \voperators\v411. for times, have the conventional meaning. The exception TIME_ERROR is raised by the function TIME_OF if the actual parameters do not form a proper date. This exception is also raised by the operators "+" and "-" if, for the given operands, these operators cannot return a date whose year number is in the range of the corresponding subtype, or if the operator "-" cannot return a result that is in the range of the type DURATION. package CALENDAR is type TIME is private; subtype YEAR_NUMBER is INTEGER range 1901 .. 2099; subtype MONTH_NUMBER is INTEGER range 1 .. 12; subtype DAY_NUMBER is INTEGER range 1 .. 31; subtype DAY_DURATION is DURATION range 0.0 .. 86_400.0; function CLOCK return TIME; function YEAR (DATE : TIME) return YEAR_NUMBER; function MONTH (DATE : TIME) return MONTH_NUMBER; function DAY (DATE : TIME) return DAY_NUMBER; function SECONDS(DATE : TIME) return DAY_DURATION; procedure SPLIT (DATE : in TIME; YEAR : out YEAR_NUMBER; MONTH : out MONTH_NUMBER; DAY : out DAY_NUMBER; SECONDS : out DAY_DURATION); function TIME_OF(YEAR : YEAR_NUMBER; MONTH : MONTH_NUMBER; DAY : DAY_NUMBER; SECONDS : DAY_DURATION := 0.0) return TIME; function "+" (LEFT : TIME; RIGHT : DURATION) return TIME; function "+" (LEFT : DURATION; RIGHT : TIME) return TIME; function "-" (LEFT : TIME; RIGHT : DURATION) return TIME; function "-" (LEFT : TIME; RIGHT : TIME) return DURATION; function "<" (LEFT, RIGHT : TIME) return BOOLEAN; function "<=" (LEFT, RIGHT : TIME) return BOOLEAN; function ">" (LEFT, RIGHT : TIME) return BOOLEAN; function ">=" (LEFT, RIGHT : TIME) return BOOLEAN; TIME_ERROR : exception; -- can be raised by TIME_OF, "+", and "-" private -- implementation-dependent end; \uExamples:\n delay 3.0; -- delay 3.0 seconds declare use CALENDAR; -- INTERVAL is a global constant of type DURATION NEXT_TIME : TIME := CLOCK + INTERVAL; begin loop delay NEXT_TIME - CLOCK; -- some actions NEXT_TIME := NEXT_TIME + INTERVAL; end loop; end; \uNotes:\n The second example causes the loop to be repeated every INTERVAL seconds on average. This interval between two successive iterations is only approximate. However, there will be no cumulative drift as long as the duration of each iteration is (sufficiently) less than INTERVAL. 9.7 \uSelect Statements\n There are three forms of select statements. One form provides a \vselective\v908. \vwait\v908. for one or more alternatives. The other two provide conditional and timed entry calls. select_statement ::= selective_wait | \vconditional_entry_call\v909. | \vtimed_entry_call\v910. More details: 9.7.1 \vSelective Waits\v908. 9.7.2 \vConditional Entry Calls\v909. 9.7.3 \vTimed Entry Calls\v910. 9.7.1 \uSelective Waits\n This form of the \vselect statement\v907. allows a combination of waiting for, and selecting from, one or more alternatives. The selection can depend on \vconditions\v504. associated with each alternative of the selective wait. selective_wait ::= select select_alternative {or select_alternative} [else \vsequence_of_statements\v501.] end select; select_alternative ::= [when condition =>] selective_wait_alternative selective_wait_alternative ::= accept_alternative | delay_alternative | terminate_alternative accept_alternative ::= accept_statement [sequence_of_statements] delay_alternative ::= \vdelay_statement\v906. [sequence_of_statements] terminate_alternative ::= terminate; A selective wait must contain at least one accept alternative. In addition a selective wait can contain either a terminate alternative (only one), or one or more delay alternatives, or an else part; these three possibilities are mutually exclusive. A select alternative is said to be open if it does not start with when and a condition, or if the condition is TRUE. It is said to be closed otherwise. For the execution of a selective wait, any conditions specified after when are evaluated in some order that is not defined by the language; open alternatives are thus determined. For an open delay alternative, the \vdelay\v906. \vexpression\v906. is also evaluated. Similarly, for an open accept alternative for an \ventry\v905. of a family, the \ventry index\v905. is also evaluated. Selection and execution of one open alternative, or of the else part, then completes the execution of the selective wait; the rules for this selection are described below. Open accept alternatives are first considered. Selection of one such alternative takes place immediately if a corresponding \vrendezvous\v905. is possible, that is, if there is a corresponding \ventry call\v905. issued by another \vtask\v900. and waiting to be accepted. If several alternatives can thus be selected, one of them is selected arbitrarily (that is, the language does not define which one). When such an alternative is selected, the corresponding \vaccept statement\v905. and possible subsequent statements are executed. If no rendezvous is immediately possible and there is no else part, the task waits until an open selective wait alternative can be selected. Selection of the other forms of alternative or of an else part is performed as follows: - An open delay alternative will be selected if no accept alternative can be selected before the specified delay has elapsed (immediately, for a negative or zero delay in the absence of \vqueued entry calls\v905.); any subsequent statements of the alternative are then executed. If several delay alternatives can thus be selected (that is, if they have the same delay), one of them is selected arbitrarily. - The else part is selected and its statements are executed if no accept alternative can be immediately selected, in particular, if all alternatives are closed. - An open terminate alternative is selected if the conditions stated in section 9.4 are satisfied. It is a consequence of other rules that a terminate alternative cannot be selected while there is a queued entry call for any entry of the task. The \vexception PROGRAM_ERROR\v1101. is raised if all alternatives are closed and there is no else part. Examples of a select statement: select \uaccept\n DRIVER_AWAKE_SIGNAL; or delay 30.0*SECONDS; STOP_THE_TRAIN; end select; Example of a task body with a select statement: task body RESOURCE is BUSY : BOOLEAN := FALSE; begin loop select when not BUSY => \uaccept\n SEIZE do BUSY := TRUE; end; or \uaccept\n RELEASE do BUSY := FALSE; end; or terminate; end select; end loop; end RESOURCE; \uNotes:\n A selective wait is allowed to have several open delay alternatives. A selective wait is allowed to have several open accept alternatives for the same entry. 9.7.2 \uConditional Entry Calls\n A conditional entry call issues an entry call that is then canceled if a \vrendezvous\v905. is not immediately possible. conditional_entry_call ::= select \ventry_call_statement\v905. [sequence_of_statements] else sequence_of_statements end select; For the execution of a conditional entry call, the entry name is first evaluated. This is followed by any \vevaluations\v411. required for actual parameters as in the case of a subprogram call (see 6.4). The entry call is canceled if the execution of the called \vtask\v900. has not reached a point where it is ready to accept the call (that is, either an \vaccept statement\v905. for the corresponding entry, or a \vselect statement\v907. with an open accept alternative for the entry), or if there are prior \vqueued entry\v905. \vcalls\v905. for this entry. If the called task has reached a select statement, the entry call is canceled if an accept alternative for this entry is not selected. If the entry call is canceled, the statements of the else part are executed. Otherwise, the rendezvous takes place; and the optional \vsequence of statements\v501. after the entry call is then executed. The execution of a conditional entry call raises the \vexception\v1101. \vTASKING_ERROR\v1101. if the called task has already completed its execution (see also 9.10 for the case when the called \vtask becomes abnormal\v913.). Example: procedure SPIN(R : RESOURCE) is begin loop select R.SEIZE; return; else \unull\n; -- busy waiting end select; end loop; end; 9.7.3 \uTimed Entry Calls\n A timed entry call issues an entry call that is canceled if a \vrendezvous\v905. is not started within a given delay. timed_entry_call ::= select \ventry_call_statement\v905. [sequence_of_statements] or delay_alternative end select; For the execution of a timed entry call, the entry name is first evaluated. This is followed by any \vevaluations\v411. required for \vactual parameters\v606. as in the case of a subprogram call (see 6.4). The \vexpression\v410. stating the delay is then evaluated, and the entry call is finally issued. If a rendezvous can be started within the specified \vduration\v906. (or immediately, as for a \vconditional entry call\v909., for a negative or zero delay), it is performed and the optional \vsequence of statements\v501. after the entry call is then executed. Otherwise, the entry call is canceled when the specified duration has expired, and the optional sequence of statements of the delay alternative is executed. The execution of a timed entry call raises the \vexception TASKING_ERROR\v1101. if the called \vtask completes\v904. its execution before accepting the call (see also 9.10 for the case when the called \vtask becomes abnormal\v913.). Example: select CONTROLLER.REQUEST(MEDIUM)(SOME_ITEM); or delay 45.0; -- controller too busy, try something else end select; 9.8 \uPriorities\n Each \vtask\v900. may (but need not) have a priority, which is a value of the \vsubtype\v305. PRIORITY (of the \vtype INTEGER\v314.) declared in the predefined library \vpackage SYSTEM\v1308.. A lower value indicates a lower degree of urgency; the range of priorities is implementation-defined. A priority is associated with a task if a \vpragma\v210. pragma PRIORITY (\vstatic_expression\v422.); appears in the corresponding \vtask specification\v901.; the priority is given by the value of the expression. A priority is associated with the \vmain\v1001. \vprogram\v1001. if such a pragma appears in its outermost \vdeclarative part\v333.. At most one such pragma can appear within a given task specification or for a subprogram that is a library unit, and these are the only allowed places for this pragma. A pragma PRIORITY has no effect if it occurs in a subprogram other than the main program. The specification of a priority is an indication given to assist the implementation in the allocation of processing resources to parallel tasks when there are more tasks eligible for execution than can be supported simultaneously by the available processing resources. The effect of priorities on scheduling is defined by the following rule: If two tasks with different priorities are both eligible for execution and could sensibly be executed using the same physical processors and the same other processing resources, then it cannot be the case that the task with the lower priority is executing while the task with the higher priority is not. For tasks of the same priority, the scheduling order is not defined by the language. For tasks without explicit priority, the scheduling rules are not defined, except when such tasks are engaged in a \vrendezvous\v905.. If the priorities of both tasks engaged in a rendezvous are defined, the rendezvous is executed with the higher of the two priorities. If only one of the two priorities is defined, the rendezvous is executed with at least that priority. If neither is defined, the priority of the rendezvous is undefined. \uNotes:\n The priority of a task is static and therefore fixed. However, the priority during a rendezvous is not necessarily static since it also depends on the priority of the task calling the entry. Priorities should be used only to indicate relative degrees of urgency; they should not be used for task synchronization. 9.9 \uTask and Entry Attributes\n For a \vtask object\v902. or value T the following \vattributes\v405. are defined: T'CALLABLE Yields the value \vFALSE\v313. when the execution of the \vtask\v900. designated by T is either \vcompleted\v904. or \vterminated\v904., or when the \vtask is abnormal\v913.. Yields the value \vTRUE\v313. otherwise. The value of this attribute is of the predefined \vtype BOOLEAN\v313.. T'TERMINATED Yields the value TRUE if the task \vdesignated\v901. by T is terminated. Yields the value FALSE otherwise. The value of this attribute is of the predefined type BOOLEAN. In addition, the representation attributes STORAGE_SIZE, SIZE, and ADDRESS are defined for a task object T or a \vtask type\v901. T (see 13.7.2). The attribute COUNT is defined for an \ventry\v905. E of a task unit T. The entry can be either a single entry or an entry of a family (in either case the name of the single entry or entry family can be either a simple or an expanded name). This attribute is only allowed within the body of T, but excluding within any program unit that is, itself, inner to the body of T. E'COUNT Yields the number of entry calls presently \vqueued\v905. on the entry E (if the attribute is evaluated by the execution of an \vaccept statement\v905. for the entry E, the count does not include the calling task). The value of this attribute is of the \vtype universal_integer\v314.. Note: Algorithms interrogating the attribute E'COUNT should take precautions to allow for the increase of the value of this attribute for incoming entry calls, and its decrease, for example with \vtimed entry calls\v910.. 9.10 \uAbort Statements\n An abort statement causes one or more \vtasks\v900. to become abnormal, thus preventing any further \vrendezvous\v905. with such tasks. abort_statement ::= \uabort\n task_name {, task_name}; The determination of the type of each task name uses the fact that the type of the \vname\v401. is a task type. For the execution of an abort \vstatement\v500., the given task names are \vevaluated\v401. in some order that is not defined by the language. Each named task then becomes abnormal unless it is already \vterminated\v904.; similarly, any task that depends on a named task becomes abnormal unless it is already terminated. Any abnormal task whose execution is suspended at an \vaccept statement\v905., a \vselect statement\v907., or a \vdelay statement\v906. becomes completed; any abnormal task whose execution is suspended at an entry call, and that is not yet in a corresponding rendezvous, becomes completed and is removed from the entry \vqueue\v905.; any abnormal task that has not yet started its \vactivation\v903. becomes completed (and hence also terminated). This completes the execution of the abort statement. The completion of any other abnormal task need not happen before completion of the abort statement. It must happen no later than when the abnormal task reaches a synchronization point that is one of the following: the end of its activation; a point where it causes the activation of another task; an entry call; the start or the end of an accept statement; a select statement; a delay statement; an \vexception handler\v1102.; or an abort statement. If a task that calls an entry becomes \vabnormal while in a\v1107. \vrendezvous\v1107., its termination does not take place before the completion of the rendezvous (see 11.5). The call of an entry of an abnormal task raises the \vexception TASKING_ERROR\v1101. at the place of the call. Similarly, the exception TASKING_ERROR is raised for any task that has called an entry of an abnormal task, if the entry call is still queued or if the rendezvous is not yet finished (whether the entry call is an \ventry call statement\v905., or a \vconditional\v909. or \vtimed entry\v910. \vcall\v910.); the exception is raised no later than the completion of the abnormal task. The value of the \vattribute CALLABLE\v912. is \vFALSE\v313. for any task that is abnormal (or completed). If the abnormal completion of a task takes place while the task updates a variable, then the value of this variable is undefined. Example: \uabort\n USER, TERMINAL.\uall\n, POOL(3); \uNotes:\n An abort statement should be used only in extremely severe situations requiring unconditional termination. A task is allowed to abort any task, including itself. 9.11 \uShared Variables\n The normal means of communicating values between tasks is by \ventry calls\v905. and \vaccept statements\v905.. If two \vtasks\v900. read or update a shared \vvariable\v303. (that is, a variable accessible by both), then neither of them may assume anything about the order in which the other performs its operations, except at the points where they synchronize. Two tasks are synchronized at the start and at the end of their \vrendezvous\v905.. At the start and at the end of its \vactivation\v903., a task is synchronized with the task that causes this activation. A task that has completed its execution is synchronized with any other task. For the actions performed by a program that uses shared variables, the following assumptions can always be made: - If between two synchronization points of a task, this task reads a shared variable whose \vtype\v305. is a scalar or access type, then the variable is not updated by any other task at any time between these two points. - If between two synchronization points of a task, this task updates a shared variable whose type is a scalar or access type, then the variable is neither read nor updated by any other task at any time between these two points. The execution of the program is \verroneous\v108. if any of these assumptions is violated. If a given task \vreads the value\v602. of a shared variable, the above assumptions allow an implementation to maintain local copies of the value (for example, in registers or in some other form of temporary storage); and for as long as the given task neither reaches a synchronization point nor \vupdates the\v602. \vvalue\v602. of the shared variable, the above assumptions imply that, for the given task, reading a local copy is equivalent to reading the shared variable itself. Similarly, if a given task updates the value of a shared variable, the above assumptions allow an implementation to maintain a local copy of the value, and to defer the effective store of the local copy into the shared variable until a synchronization point, provided that every further read or update of the variable by the given task is treated as a read or update of the local copy. On the other hand, an implementation is not allowed to introduce a store, unless this store would also be executed in the \vcanonical order\v1108.. The \vpragma\v210. SHARED can be used to specify that every read or update of a variable is a synchronization point for that variable; that is, the above assumptions always hold for the given variable (but not necessarily for other variables). The form of this pragma is as follows: pragma SHARED(variable_simple_name); This pragma is allowed only for a variable declared by an object declaration and whose type is a scalar or access type; the variable declaration and the pragma must both occur (in this order) immediately within the same \vdeclarative part\v333. or \vpackage specification\v701.; the pragma must appear before any occurrence of the name of the variable, other than in an address clause. An implementation must restrict the objects for which the pragma SHARED is allowed to objects for which each of direct reading and direct updating is implemented as an indivisible operation. 9.12 \uExample of Tasking\n The following example defines a buffering task to smooth variations between the speed of output of a producing task and the speed of input of some consuming task. For instance, the producing task may contain the statements loop -- produce the next character CHAR BUFFER.WRITE(CHAR); exit when CHAR = ASCII.EOT; end loop; and the consuming task may contain the statements loop BUFFER.READ(CHAR); -- consume the character CHAR exit when CHAR = ASCII.EOT; end loop; The buffering task contains an internal pool of characters processed in a round-robin fashion. The pool has two indices, an IN_INDEX denoting the space for the next input character and an OUT_INDEX denoting the space for the next output character. task BUFFER is entry READ (C : out CHARACTER); entry WRITE(C : in CHARACTER); end; task body BUFFER is POOL_SIZE : constant INTEGER := 100; POOL : \uarray\n(1 .. POOL_SIZE) of CHARACTER; COUNT : INTEGER range 0 .. POOL_SIZE := 0; IN_INDEX, OUT_INDEX : INTEGER range 1 .. POOL_SIZE := 1; begin loop select when COUNT < POOL_SIZE => \uaccept\n WRITE(C : in CHARACTER) do POOL(IN_INDEX) := C; end; IN_INDEX := IN_INDEX mod POOL_SIZE + 1; COUNT := COUNT + 1; or when COUNT > 0 => \uaccept\n READ(C : out CHARACTER) do C := POOL(OUT_INDEX); end; OUT_INDEX := OUT_INDEX mod POOL_SIZE + 1; COUNT := COUNT - 1; or terminate; end select; end loop; end BUFFER; :1000 10. \uProgram Structure and Compilation Issues\n The overall structure of programs and the facilities for separate \vcompilation\v1001. are described in this chapter. A program is a collection of one or more \vcompilation units\v1001. submitted to a compiler in one or more compilations. Each compilation unit specifies the separate compilation of a construct which can be a \vsubprogram declaration\v601. or \vbody\v603., a \vpackage\v701. \vdeclaration or body\701., a \vgeneric declaration\v1201. or \vbody\v1205., or a \vgeneric\v1206. \vinstantiation\v1206.. Alternatively this construct can be a \vsubunit\v1004., in which case it includes the body of a subprogram, package, \vtask unit\v900., or generic unit declared within another compilation unit. More details: 10.1 \vCompilation Units - Library Units\v1001. 10.2 \vSubunits of Compilation Units\v1004. 10.3 \vOrder of Compilation\v1006. 10.4 \vThe Program Library\v1007. 10.5 \vElaboration of Library Units\v1008. 10.6 \vProgram Optimization\v1009. :1001 10.1 \uCompilation Units - Library Units\n The text of a program can be submitted to the compiler in one or more compilations. Each compilation is a succession of compilation units. compilation ::= {compilation_unit} compilation_unit ::= \vcontext_clause\v1002. \vlibrary_unit\v1008. | context_clause secondary_unit library_unit ::= subprogram_declaration | \vpackage_declaration\v701. | \vgeneric_declaration\v1201. | \vgeneric_instantiation\v1206. | subprogram_body secondary_unit ::= library_unit_body | \vsubunit\v1004. library_unit_body ::= subprogram_body | \vpackage_body\v701. The compilation units of a program are said to belong to a program library. A compilation unit defines either a library unit or a secondary unit. A secondary unit is either the separately compiled \vproper body\v333. of a library unit, or a subunit of another compilation unit. The \vdesignator\v601. of a separately compiled \vsubprogram\v600. (whether a library unit or a subunit) \vmust\v108. be an \videntifier\v203.. Within a program library the simple \vnames\v401. of all library units must be distinct identifiers. The effect of compiling a library unit is to define (or redefine) this unit as one that belongs to the program library. For the \vvisibility\v803. rules, each library unit acts as a \vdeclaration\v301. that \voccurs immediately within\v801. the \vpackage STANDARD\v806.. The effect of compiling a secondary unit is to define the body of a library unit, or in the case of a subunit, to define the proper body of a \vprogram\v600. \vunit\v600. that is declared within another compilation unit. A \vsubprogram body\v603. given in a compilation unit is interpreted as a secondary unit if the program library already contains a library unit that is a subprogram with the same name; it is otherwise interpreted both as a library unit and as the corresponding library unit body (that is, as a secondary unit). The compilation units of a compilation are compiled in the given order. A \vpragma\v210. that applies to the whole of a compilation must appear before the first compilation unit of that compilation. A subprogram that is a library unit can be used as a main program in the usual sense. Each main program acts as if called by some \venvironment\v1007. \vtask\v900.; the means by which this execution is initiated are not prescribed by the language definition. An implementation may impose certain requirements on the parameters and on the result, if any, of a main program (these requirements must be stated in Appendix F). In any case, every implementation is required to \vallow\v108., at least, main programs that are parameterless \vprocedures\v601., and every main program must be a subprogram that is a library unit. \uNotes:\n A simple program may consist of a single compilation unit. A compilation need not have any compilation units; for example, its text can consist of pragmas. The designator of a library function cannot be an \voperator symbol\v601., but a \vrenaming declaration\v805. is allowed to rename a library function as an \voperator\v411.. Two library subprograms must have distinct simple names and hence cannot overload each other. However, renaming declarations are allowed to define overloaded names for such subprograms, and a locally declared subprogram is allowed to overload a library subprogram. The expanded name STANDARD.L can be used for a library unit L (unless the name STANDARD is hidden) since library units act as declarations that occur immediately within the package STANDARD. More details: 10.1.1 \vContext Clauses - With Clauses\v1002. 10.1.2 \vExamples of Compilation Units\v1003. :1002 10.1.1 \uContext Clauses - With Clauses\n A context clause is used to specify the \vlibrary units\v1001. whose \vnames\v401. are needed within a \vcompilation unit\v1001.. context_clause ::= {with_clause {use_clause}} with_clause ::= with unit_simple_name {, unit_simple_name}; The names that appear in a context clause \vmust\v108. be the \vsimple names\v401. of library units. The simple name of any library unit is \vallowed\v108. within a with clause. The only names allowed in a \vuse clause\v804. of a context clause are the simple names of library \vpackages\v700. mentioned by previous with clauses of the context clause. A simple name declared by a renaming declaration is not allowed in a context clause. The with clauses and use clauses of the context clause of a library unit apply to this library unit and also to the \vsecondary unit\v1001. that defines the corresponding body (whether such a clause is repeated or not for this unit). Similarly, the with clauses and use clauses of the context clause of a compilation unit apply to this unit and also to its \vsubunits\v1004., if any. If a library unit is named by a with clause that applies to a compilation unit, then this library unit is directly visible within the compilation unit, except where hidden; the library unit is visible as if declared immediately within the \vpackage STANDARD\v806.. Dependences among compilation units are defined by with clauses; that is, a compilation unit that mentions other library units in its with clauses depends on those library units. These dependences between units are taken into account for the determination of the allowed order of compilation (and recompilation) of compilation units, as explained in section 10.3, and for the determination of the allowed order of \velaboration\v333. of compilation units, as explained in section 10.5. \uNotes:\n A library unit named by a with clause of a compilation unit is visible (except where hidden) within the compilation unit and hence can be used as a corresponding \vprogram unit\v600.. Thus within the compilation unit, the name of a library package can be given in use clauses and can be used to form expanded names; a library subprogram can be called; and \vinstances\v1206. of a library \vgeneric unit\v1201. can be declared. The rules given for with clauses are such that the same effect is obtained whether the name of a library unit is mentioned once or more than once by the applicable with clauses, or even within a given with clause. Example 1 : A \vmain program\v1001.: The following is an example of a main program consisting of a single compilation unit: a \vprocedure\v601. for printing the real roots of a quadratic equation. The predefined package TEXT_IO and a user-defined package REAL_OPERATIONS (containing the definition of the \vtype\v305. REAL and of the packages REAL_IO and REAL_FUNCTIONS) are assumed to be already present in the program library. Such packages may be used by other main programs. with TEXT_IO, REAL_OPERATIONS; use REAL_OPERATIONS; procedure QUADRATIC_EQUATION is A, B, C, D : REAL; use REAL_IO, -- achieves \vdirect visibility\v803. of GET and PUT for REAL TEXT_IO, -- achieves direct visibility of PUT for strings and of NEW_LINE REAL_FUNCTIONS; -- achieves direct visibility of SQRT begin GET(A); GET(B); GET(C); D := B**2 - 4.0*A*C; if D < 0.0 then PUT("Imaginary Roots."); else PUT("Real Roots : X1 = "); PUT((-B - SQRT(D))/(2.0*A)); PUT(" X2 = "); PUT((-B + SQRT(D))/(2.0*A)); end if; NEW_LINE; end QUADRATIC_EQUATION; Notes on the example: The with clauses of a compilation unit need only mention the names of those library subprograms and packages whose \vvisibility\v803. is actually necessary within the unit. They need not (and should not) mention other library units that are used in turn by some of the units named in the with clauses, unless these other library units are also used directly by the current compilation unit. For example, the body of the package REAL_OPERATIONS may need elementary operations provided by other packages. The latter packages should not be named by the with clause of QUADRATIC_EQUATION since these elementary operations are not directly called within its body. :1003 10.1.2 \uExamples of Compilation Units\n A \vcompilation unit\v1001. can be split into a number of compilation units. For example, consider the following \vprogram\v1000.. procedure PROCESSOR is SMALL : constant := 20; TOTAL : INTEGER := 0; package STOCK is LIMIT : constant := 1 TABLE : \uarray\n (1 .. LIMIT) of INTEGER; procedure RESTART; end STOCK; \vpackage body\v701. STOCK is procedure RESTART is begin for N in 1 .. LIMIT loop TABLE(N) := N; end loop; end; begin RESTART; end STOCK; procedure UPDATE(X : INTEGER) is use STOCK; begin ... TABLE(X) := TABLE(X) + SMALL; ... end UPDATE; begin ... STOCK.RESTART; -- reinitializes TABLE ... end PROCESSOR; The following three compilation units define a program with an effect equivalent to the above example (the broken lines between compilation units serve to remind the reader that these units need not be contiguous texts). Example 2 : Several compilation units: package STOCK is LIMIT : constant := 1 TABLE : \uarray\n (1 .. LIMIT) of INTEGER; procedure RESTART; end STOCK; ------------------------------------------------- package body STOCK is procedure RESTART is begin for N in 1 .. LIMIT loop TABLE(N) := N; end loop; end; begin RESTART; end STOCK; ------------------------------------------------- with STOCK; procedure PROCESSOR is SMALL : constant := 20; TOTAL : INTEGER := 0; procedure UPDATE(X : INTEGER) is use STOCK; begin ... TABLE(X) := TABLE(X) + SMALL; ... end UPDATE; begin ... STOCK.RESTART; -- reinitializes TABLE ... end PROCESSOR; Note that in the latter version, the \vpackage\v700. STOCK has no \vvisibility\v803. of outer \videntifiers\v203. other than the predefined identifiers (of the package STANDARD). In particular, STOCK does not use any identifier declared in PROCESSOR such as SMALL or TOTAL; otherwise STOCK could not have been extracted from PROCESSOR in the above manner. The procedure PROCESSOR, on the other hand, depends on STOCK and mentions this package in a \vwith\v1002. \vclause\v1002.. This permits the inner occurrences of STOCK in the expanded name STOCK.RESTART and in the \vuse clause\v804.. These three compilation units can be submitted in one or more compilations. For example, it is possible to submit the \vpackage specification\v701. and the package body together and in this order in a single compilation. :1004 10.2 \uSubunits of Compilation Units\n A subunit is used for the \vseparate compilation\v1001. of the proper body of a \vprogram unit\v600. declared within another \vcompilation unit\v1001.. This method of splitting a \vprogram\v1000. permits hierarchical program development. body_stub ::= \vsubprogram_specification\v601. is separate; | \vpackage body\701. package_simple_name is separate; | \vtask body\901. task_simple_name is separate; subunit ::= separate (parent_unit_name) proper_body A body stub is only allowed as the body of a program unit (a subprogram, a \vpackage\v700., a \vtask unit\v901., or a \vgeneric unit\v1200.) if the body stub \voccurs\v801. \vimmediately within\v801. either the specification of a library package or the \vdeclarative part\v333. of another compilation unit. If the body of a program unit is a body stub, a separately compiled subunit containing the corresponding proper body is required. In the case of a subprogram, the subprogram specifications given in the \vproper body\v333. and in the body stub must \vconform\v604.. Each subunit mentions the \vname\v401. of its parent unit, that is, the compilation unit where the corresponding body stub is given. If the parent unit is a \vlibrary unit\v1001., it is called the ancestor library unit. If the parent unit is itself a subunit, the parent unit name must be given in full as an \vexpanded name\v404., starting with the \vsimple name\v401. of the ancestor library unit. The simple names of all subunits that have the same ancestor library unit must be distinct \videntifiers\v203.. \vVisibility\v803. within the proper body of a subunit is the visibility that would be obtained at the place of the corresponding body stub (within the parent unit) if the \vwith clauses\v1002. and \vuse clauses\v804. of the subunit were appended to the \vcontext clause\v1002. of the parent unit. If the parent unit is itself a subunit, then the same rule is used to define the visibility within the proper body of the parent unit. The effect of the \velaboration\v333. of a body stub is to elaborate the proper body of the subunit. \uNotes:\n Two subunits of different library units in the same program library need not have distinct identifiers. In any case, their full expanded names are distinct, since the simple names of library units are distinct and since the simple names of all subunits that have a given library unit as ancestor unit are also distinct. By means of renaming \vdeclarations\v301., overloaded \vsubprogram\v600. names that rename (distinct) subunits can be introduced. A library unit that is named by the with clause of a subunit can be hidden by a declaration (with the same identifier) given in the proper body of the subunit. Moreover, such a library unit can even be \vhidden by a declaration\v803. given within a parent unit since a library unit acts as if declared in STANDARD; this however does not affect the interpretation of the with clauses themselves, since only names of library units can appear in with clauses. More details: 10.2.1 \vExamples of Subunits\v1005. :1005 10.2.1 \uExamples of Subunits\n The \vprocedure\v600. TOP is first written as a \vcompilation unit\v1001. without subunits. with TEXT_IO; procedure TOP is type REAL is digits 10; R, S : REAL := 1.0; \vpackage\v700. FACILITY is PI : constant := 3.14159_26536; function F(X : REAL) return REAL; procedure G(Y, Z : REAL); end FACILITY; \vpackage body\v701. FACILITY is -- some \vlocal declarations\v801. followed by function F(X : REAL) return REAL is begin -- sequence of statements of F ... end F; procedure G(Y, Z : REAL) is -- local procedures using TEXT_IO ... begin -- sequence of statements of G ... end G; end FACILITY; procedure TRANSFORM(U : in out REAL) is use FACILITY; begin U := F(U); ... end TRANSFORM; begin -- TOP TRANSFORM(R); ... FACILITY.G(R, S); end TOP; The body of the package FACILITY and that of the procedure TRANSFORM can be made into separate subunits of TOP. Similarly, the body of the procedure G can be made into a subunit of FACILITY as follows. Example 3: procedure TOP is type REAL is digits 10; R, S : REAL := 1.0; package FACILITY is PI : constant := 3.14159_26536; function F(X : REAL) return REAL; procedure G(Y, Z : REAL); end FACILITY; package body FACILITY is separate; -- stub of FACILITY procedure TRANSFORM(U : in out REAL) is separate; -- stub of TRANSFORM begin -- TOP TRANSFORM(R); ... FACILITY.G(R, S); end TOP; ------------------------------------------------- separate (TOP) procedure TRANSFORM(U : in out REAL) is use FACILITY; begin U := F(U); ... end TRANSFORM; ------------------------------------------------- separate (TOP) package body FACILITY is -- some local declarations followed by function F(X : REAL) return REAL is begin -- sequence of statements of F ... end F; procedure G(Y, Z : REAL) is separate; -- stub of G end FACILITY; ------------------------------------------------- with TEXT_IO; separate (TOP.FACILITY) -- full name of FACILITY procedure G(Y, Z : REAL) is -- local procedures using TEXT_IO ... begin -- sequence of statements of G ... end G; In the above example TRANSFORM and FACILITY are subunits of TOP, and G is a subunit of FACILITY. The \vvisibility\v803. in the split version is the same as in the initial version except for one change: since TEXT_IO is only used within G, the corresponding \vwith clause\v1002. is written for G instead of for TOP. Apart from this change, the same \videntifiers\v203. are visible at corresponding program points in the two versions. For example, all of the following are (directly) visible within the \vproper body\v333. of the subunit G: the procedure TOP, the \vtype\v305. REAL, the \vvariables\v303. R and S, the package FACILITY and the contained \vnamed number\v302. PI and \vsubprograms\v600. F and G. :1006 10.3 \uOrder of Compilation\n The rules defining the order in which units can be compiled are direct consequences of the \vvisibility\v803. rules and, in particular, of the fact that any \vlibrary unit\v1001. that is mentioned by the \vcontext clause\v1002. of a \vcompilation\v1001. unit is visible in the \vcompilation unit\v1001.. A compilation unit must be compiled after all library units \vnamed\v401. by its context clause. A \vsecondary unit\v1001. that is a subprogram or \vpackage body\v701. must be compiled after the corresponding library unit. Any \vsubunit\v1004. of a parent compilation unit must be compiled after the parent compilation unit. If any error is detected while attempting to compile a compilation unit, then the attempted compilation is rejected and it has no effect whatsoever on the program library; the same holds for recompilations (no compilation unit can become obsolete because of such a recompilation). The order in which the compilation units of a program are compiled must be consistent with the partial ordering defined by the above rules. Similar rules apply for recompilations. A compilation unit is potentially affected by a change in any library unit named by its context clause. A secondary unit is potentially affected by a change in the corresponding library unit. The subunits of a parent compilation unit are potentially affected by a change of the parent compilation unit. If a compilation unit is successfully recompiled, the compilation units potentially affected by this change are obsolete and must be recompiled unless they are no longer needed. An implementation may be able to reduce the compilation costs if it can deduce that some of the potentially affected units are not actually affected by the change. The subunits of a unit can be recompiled without affecting the unit itself. Similarly, changes in a subprogram or \vpackage body\v701. do not affect other compilation units (apart from the subunits of the body) since these compilation units only have access to the subprogram or package specification. An implementation is only allowed to deviate from this rule for inline inclusions, for certain compiler optimizations, and for certain implementations of generic program units, as described below. - If a \vpragma INLINE\v605. is applied to a \vsubprogram declaration\v601. given in a \vpackage specification\v701., inline inclusion will only be achieved if the package body is compiled before units calling the subprogram. In such a case, inline inclusion creates a dependence of the calling unit on the package body, and the compiler must recognize this dependence when deciding on the need for recompilation. If a calling unit is compiled before the package body, the pragma may be ignored by the compiler for such calls (a warning that inline inclusion was not achieved may be issued). Similar considerations apply to a separately compiled subprogram for which an INLINE pragma is specified. - For optimization purposes, an implementation may compile several units of a given compilation in a way that creates further dependences among these compilation units. The compiler must then take these dependences into account when deciding on the need for recompilations. - An implementation may require that a \vgeneric declaration\v1201. and the corresponding \vproper body\v333. be part of the same compilation, whether the generic unit is itself separately compiled or is local to another compilation unit. An implementation may also require that subunits of a \vgeneric unit\v1200. be part of the same compilation. Examples of Compilation Order: (a) In example 1 (see 10.1.1): The \vprocedure\v601. QUADRATIC_EQUATION must be compiled after the library packages TEXT_IO and REAL_OPERATIONS since they appear in its \vwith clause\v1002.. (b) In example 2 (see 10.1.2): The package body STOCK must be compiled after the corresponding package specification. (c) In example 2 (see 10.1.2): The specification of the package STOCK must be compiled before the procedure PROCESSOR. On the other hand, the procedure PROCESSOR can be compiled either before or after the package body STOCK. (d) In example 3 (see 10.2.1): The procedure G must be compiled after the package TEXT_IO since this package is named by the with clause of G. On the other hand, TEXT_IO can be compiled either before or after TOP. (e) In example 3 (see 10.2.1): The subunits TRANSFORM and FACILITY must be compiled after the main program TOP. Similarly, the subunit G must be compiled after its \vparent unit\v1004. FACILITY. \uNotes:\n For library packages, it follows from the recompilation rules that a package body is made obsolete by the recompilation of the corresponding specification. If the new package specification is such that a package body is not required (that is, if the package specification does not contain the declaration of a program unit), then the recompilation of a body for this package is not required. In any case, the obsolete package body must not be used and can therefore be deleted from the program library. :1007 10.4 \uThe Program Library\n Compilers are required to enforce the language rules in the same manner for a program consisting of several \vcompilation units\v1001. (and \vsubunits\v1004.) as for a program submitted as a single compilation. Consequently, a library file containing information on the compilation units of the program library must be maintained by the compiler or compiling environment. This information may include symbol tables and other information pertaining to the order of previous compilations. A normal submission to the compiler consists of the compilation unit(s) and the library file. The latter is used for checks and is updated for each compilation unit successfully compiled. \uNotes:\n A single \vprogram\v1001. library is implied for the compilation units of a compilation. The possible existence of different \vprogram libraries\v1001. and the means by which they are named are not concerns of the language definition; they are concerns of the programming environment. There should be commands for creating the program library of a given program or of a given family of programs. These commands may permit the reuse of units of other program libraries. Finally, there should be commands for interrogating the status of the units of a program library. The form of these commands is not specified by the language definition. :1008 10.5 \uElaboration of Library Units\n Before the execution of a main program, all \vlibrary units\v1001. needed by the main program are elaborated, as well as the corresponding library unit bodies, if any. The library units needed by the main program are: those \vnamed\v401. by with clauses applicable to the \vmain program\v1001., to its body, and to its \vsubunits\v1004.; those named by \vwith clauses\v1002. applicable to these library units themselves, to the corresponding library unit bodies, and to their subunits; and so on, in a transitive manner. The \velaboration\v333. of these library units and of the corresponding library unit bodies is performed in an order consistent with the partial ordering defined by the with clauses (see 10.3). In addition, a library unit mentioned by the \vcontext clause\v1002. of a subunit must be elaborated before the body of the ancestor library unit of the subunit. An order of elaboration that is consistent with this partial ordering does not always ensure that each library unit body is elaborated before any other \vcompilation unit\v1001. whose elaboration necessitates that the library unit body be already elaborated. If the prior elaboration of library unit bodies is needed, this can be requested by a \vpragma\v210. ELABORATE. The form of this pragma is as follows: pragma ELABORATE (library_unit_simple_name {, library_unit_simple_name}); These pragmas are only \vallowed\v108. immediately after the context clause of a compilation unit (before the subsequent library unit or \vsecondary unit\v1001.). Each \vargument of such a pragma\v210. must be the \vsimple name\v401. of a library unit mentioned by the context clause, and this library unit must have a library unit body. Such a pragma specifies that the library unit body must be elaborated before the given compilation unit. If the given compilation unit is a subunit, the library unit body must be elaborated before the body of the ancestor library unit of the subunit. The program is \villegal\v108. if no consistent order can be found (that is, if a circularity exists). The elaboration of the compilation units of the program is performed \vin some order\v108. that is otherwise not defined by the language. :1009 10.6 \uProgram Optimization\n Optimization of the elaboration of \vdeclarations\v301. and the execution of \vstatements\v500. may be performed by compilers. In particular, a compiler may be able to optimize a \vprogram\v1000. by evaluating certain \vexpressions\v410., in addition to those that are \vstatic expressions\v422.. Should one of these expressions, whether static or not, be such that an \vexception\v1100. would be raised by its \vevaluation\v411., then the code in that path of the program can be replaced by code to raise the exception; the same holds for exceptions raised by the evaluation of names and simple expressions. (See also section 11.6.) A compiler may find that some statements or \vsubprograms\v600. will never be executed, for example, if their execution depends on a \vcondition\v504. known to be FALSE. The corresponding object machine code can then be omitted. This rule permits the effect of conditional compilation within the language. Note: An expression whose evaluation is known to raise an exception need not represent an error if it occurs in a statement or subprogram that is never executed. The compiler may warn the programmer of a potential error. :1100 11. \uExceptions\n This chapter defines the facilities for dealing with \verrors\v108. or other exceptional situations that arise during program execution. Such a situation is called an exception. To raise an exception is to abandon normal program execution so as to draw attention to the fact that the corresponding situation has arisen. Executing some actions, in response to the arising of an exception, is called handling the exception. An exception declaration declares a \vname\v401. for an exception. An exception can be raised by a \vraise statement\v1103., or it can be raised by another statement or operation that \vpropagates the exception\v1105.. When an exception arises, control can be transferred to a user-provided \vexception handler\v1102. at the end of a \vblock statement\v507. or at the end of the body of a \vsubprogram\v603., \vpackage\v701., or task unit. More details: 11.1 \vException Declarations\v1101. 11.2 \vException Handlers\v1102. 11.3 \vRaise Statements\v1103. 11.4 \vException Handling\v1104. 11.5 \vExceptions Raised During Task Communication\v1107. 11.6 \vExceptions and Optimization\v1108. 11.7 \vSuppressing Checks\v1109. :1101 11.1 \uException Declarations\n An exception \vdeclaration\v301. declares a \vname\v401. for an \vexception\v1100.. The name of an exception can only be used in \vraise statements\v1103., \vexception handlers\v1102., and renaming declarations. exception_declaration ::= identifier_list : exception; An exception declaration with several \videntifiers\v203. is equivalent to a sequence of single exception declarations, as explained in section 3.2. Each single exception declaration declares a name for a different exception. In particular, if a \vgeneric unit\v1200. includes an exception declaration, the exception \vdeclarations implicitly\v1206. generated by different \vinstantiations\v1206. of the generic unit refer to distinct exceptions (but all have the same identifier). The particular exception denoted by an exception name is determined at compilation time and is the same regardless of how many times the exception declaration is elaborated. Hence, if an exception declaration occurs in a recursive \vsubprogram\v600., the exception name denotes the same exception for all invocations of the recursive subprogram. The following exceptions are predefined in the language; they are raised when the situations described are detected. CONSTRAINT_ERROR This exception is raised in any of the following situations: upon an attempt to violate a \vrange\v310. \vconstraint\v310., an \vindex constraint\v322., or a \vdiscriminant\v327. \vconstraint\v327.; upon an attempt to use a \vrecord component\v325. that does not exist for the current discriminant values; and upon an attempt to use a \vselected component\v404., an \vindexed component\v402., a \vslice\v403., or an attribute, of an \vobject\v302. designated by an \vaccess value\v330., if the object does not exist because the \vaccess value is null\v330.. NUMERIC_ERROR This exception is raised by the execution of a predefined \vnumeric operation\v315. that cannot deliver a correct result (within the declared accuracy for \vreal types\v316.); this includes the case where an implementation uses a predefined numeric operation for the execution, evaluation, or \velaboration\v333. of some construct. The rules given in section 4.5.7 define the cases in which an implementation is not required to raise this exception when such an error situation arises; see also section 11.6. PROGRAM_ERROR This exception is raised upon an attempt to call a subprogram, to \vactivate a task\v903., or to elaborate a \vgeneric\v1206. \vinstantiation\v1206., if the body of the corresponding unit has not yet been elaborated. This exception is also raised if the end of a function is reached (see 6.5); or during the execution of a \vselective wait\v908. that has no else part, if this execution determines that all alternatives are closed (see 9.7.1). Finally, depending on the implementation, this exception may be raised upon an attempt to execute an action that is \verroneous\v108., and for \vincorrect order dependences\v108.. STORAGE_ERROR This exception is raised in any of the following situations: when the dynamic storage allocated to a \vtask\v900. is exceeded; during the evaluation of an \vallocator\v421., if the space available for the \vcollection\v330. of allocated objects is exhausted; or during the elaboration of a declarative item, or during the execution of a subprogram call, if storage is not sufficient. TASKING_ERROR This exception is raised when exceptions arise during intertask communication (see 9 and 11.5). Note: The situations described above can arise without raising the corresponding exceptions, if the pragma SUPPRESS has been used to give permission to omit the corresponding checks (see 11.7). Examples of user-defined exception declarations: SINGULAR : exception; ERROR : exception; OVERFLOW, UNDERFLOW : exception; :1102 11.2 \uException Handlers\n The response to one or more \vexceptions\v1100. is specified by an exception handler. exception_handler ::= \uwhen\n exception_choice {| exception_choice} => \vsequence_of_statements\v501. exception_choice ::= exception_name | others An exception handler occurs in a construct that is either a \vblock statement\v507. or the body of a \vsubprogram\v603., \vpackage\v701., \vtask unit\v900., or \vgeneric unit\v1201.. Such a construct will be called a frame in this chapter. In each case the syntax of a frame that has exception handlers includes the following part: \ubegin\n sequence_of_statements \uexception\n exception_handler {exception_handler} \uend\n The exceptions denoted by the exception names given as exception choices of a frame must all be distinct. The exception choice others is only allowed for the last exception handler of a frame and as its only exception choice; it stands for all exceptions not listed in previous handlers of the frame, including exceptions whose \vnames\v401. are not visible at the place of the exception handler. The exception handlers of a frame handle exceptions that are raised by the execution of the sequence of statements of the frame. The exceptions handled by a given exception handler are those named by the corresponding exception choices. Example: \ubegin\n -- sequence of statements \uexception\n \uwhen\nSINGULAR | NUMERIC_ERROR => PUT(" MATRIX IS SINGULAR "); \uwhen others\n => PUT(" FATAL ERROR "); \uraise\n ERROR; end; Note: The same kinds of \vstatement\v500. are allowed in the sequence of statements of each exception handler as are allowed in the sequence of statements of the frame. For example, a \vreturn statement\v509. is allowed in a handler within a \vfunction body\v603.. :1103 11.3 \uRaise Statements\n A raise statement raises an \vexception\v1100.. raise_statement ::= raise [exception_name]; For the execution of a raise statement with an exception \vname\v401., the named exception is raised. A raise statement without an exception name is only allowed within an exception handler (but not within the \vsequence of\v501. \vstatements\v501. of a \vsubprogram\v600., \vpackage\v700., \vtask unit\v900., or \vgeneric unit\v1200., enclosed by the handler); it raises again the exception that caused transfer to the innermost enclosing handler. \uExamples:\n \uraise\n SINGULAR; \uraise\n NUMERIC_ERROR; -- explicitly raising a predefined exception \uraise\n; -- only within an exception handler :1104 11.4 \uException Handling\n When an \vexception\v1100. is raised, normal program execution is abandoned and control is transferred to an \vexception handler\v1102.. The selection of this handler depends on whether the exception is raised during the execution of \vstatements\v500. or during the \velaboration of declarations\v301.. More details: 11.4.1 \vExceptions Raised During the Execution of Statements\v1105. 11.4.2 \vExceptions Raised During the Elaboration of Declarations\v1106. :1105 11.4.1 \uExceptions Raised During the Execution of Statements\n The handling of an \vexception\v1100. raised by the execution of a \vsequence of\v501. \vstatements\v501. depends on whether the innermost frame or \vaccept statement\v905. that encloses the sequence of \vstatements\v500. is a \vframe\v1102. or an accept statement. The case where an accept statement is innermost is described in section 11.5. The case where a frame is innermost is presented here. Different actions take place, depending on whether or not this frame has a handler for the exception, and on whether the exception is raised in the sequence of statements of the frame or in that of an \vexception handler\v1102.. If an exception is raised in the sequence of statements of a frame that has a handler for the exception, execution of the sequence of statements of the frame is abandoned and control is transferred to the exception handler. The execution of the sequence of statements of the handler completes the execution of the frame (or its \velaboration\v301. if the frame is a \vpackage body\v701.). If an exception is raised in the sequence of statements of a frame that does not have a handler for the exception, execution of this sequence of statements is abandoned. The next action depends on the nature of the frame: (a) For a \vsubprogram body\v603., the same exception is raised again at the point of \vcall of the subprogram\v606., unless the \vsubprogram\v600. is the \vmain program\v1001. itself, in which case execution of the main program is abandoned. (b) For a \vblock statement\v507., the same exception is raised again immediately after the block statement (that is, within the innermost enclosing frame or accept statement). (c) For a package body that is a \vdeclarative item\v333., the same exception is raised again immediately after this declarative item (within the enclosing \vdeclarative part\v333.). If the package body is that of a \vsubunit\v1004., the exception is raised again at the place of the corresponding \vbody\v1004. \vstub\v1004.. If the \vpackage\v700. is a \vlibrary unit\v1001., execution of the main program is abandoned. (d) For a \vtask body\v901., the \vtask\v900. becomes completed. An exception that is raised again (as in the above cases (a), (b), and (c)) is said to be propagated, either by the execution of the subprogram, the execution of the block statement, or the elaboration of the package body. No propagation takes place in the case of a task body. If the frame is a subprogram or a block statement and if it has \vdependent tasks\v904., the propagation of an exception takes place only after termination of the dependent tasks. Finally, if an exception is raised in the sequence of statements of an exception handler, execution of this sequence of statements is abandoned. Subsequent actions (including propagation, if any) are as in the cases (a) to (d) above, depending on the nature of the frame. Example: function FACTORIAL (N : POSITIVE) return FLOAT is \ubegin\n \uif\n N = 1 \uthen\n \ureturn\n 1.0; \uelse\n \ureturn\n FLOAT(N) * FACTORIAL(N-1); \uend if\n; \uexception\n \uwhen\n NUMERIC_ERROR => \ureturn\n FLOAT'SAFE_LARGE; \uend\n FACTORIAL; If the multiplication raises NUMERIC_ERROR, then FLOAT'SAFE_LARGE is returned by the handler. This value will cause further \vNUMERIC_ERROR\v1101. \vexceptions\v1101. to be raised by the evaluation of the expression in each of the remaining invocations of the function, so that for large values of N the function will ultimately return the value FLOAT'SAFE_LARGE. Example: \vprocedure\v601. P is ERROR : \uexception\n; \uprocedure\n R; \uprocedure\n Q is \ubegin\n R; ... -- error situation (2) \uexception\n ... \uwhen\n ERROR => -- handler E2 ... \uend\n Q; \uprocedure\n R is \ubegin\n ... -- error situation (3) \uend\n R; \ubegin\n ... -- error situation (1) Q; ... \uexception\n ... \uwhen\n ERROR => -- handler E1 ... \uend\n P; The following situations can arise: (1) If the exception ERROR is raised in the sequence of statements of the outer procedure P, the handler E1 provided within P is used to complete the execution of P. (2) If the exception ERROR is raised in the sequence of statements of Q, the handler E2 provided within Q is used to complete the execution of Q. Control will be returned to the point of call of Q upon \vcompletion\v904. of the handler. (3) If the exception ERROR is raised in the body of R, called by Q, the execution of R is abandoned and the same exception is raised in the body of Q. The handler E2 is then used to complete the execution of Q, as in situation (2). Note that in the third situation, the exception raised in R results in (indirectly) transferring control to a handler that is part of Q and hence not enclosed by R. Note also that if a handler were provided within R for the exception choice others, situation (3) would cause execution of this handler, rather than direct termination of R. Lastly, if ERROR had been declared in R, rather than in P, the handlers E1 and E2 could not provide an explicit handler for ERROR since this identifier would not be visible within the bodies of P and Q. In situation (3), the exception could however be handled in Q by providing a handler for the exception choice others. \uNotes:\n The language does not define what happens when the execution of the main program is abandoned after an unhandled exception. The predefined exceptions are those that can be propagated by the \vbasic\v308. \voperations\v308. and the \vpredefined operators\v411.. The case of a frame that is a \vgeneric unit\v1200. is already covered by the rules for subprogram and package bodies, since the sequence of statements of such a frame is not executed but is the template for the corresponding sequences of statements of the subprograms or packages obtained by \vgeneric\v1206. \vinstantiation\v1206.. :1106 11.4.2 \uExceptions Raised During the Elaboration of Declarations\n If an \vexception\v1100. is raised during the \velaboration\v301. of the \vdeclarative part\v333. of a given \vframe\v1102., this elaboration is abandoned. The next action depends on the nature of the frame: (a) For a \vsubprogram body\v603., the same exception is raised again at the point of \vcall of the subprogram\v606., unless the \vsubprogram\v600. is the \vmain program\v1001. itself, in which case execution of the main program is abandoned. (b) For a \vblock statement\v507., the same exception is raised again immediately after the block statement. (c) For a \vpackage body\v701. that is a \vdeclarative item\v333., the same exception is raised again immediately after this declarative item, in the enclosing declarative part. If the package body is that of a \vsubunit\v1004., the exception is raised again at the place of the corresponding \vbody stub\v1004.. If the package is a \vlibrary unit\v1001., execution of the main program is abandoned. (d) For a \vtask body\v901., the \vtask becomes completed\v904., and the \vexception\v1101. \vTASKING_ERROR\v1101. is raised at the point of \vactivation\v903. of the \vtask\v900., as explained in section 9.3. Similarly, if an exception is raised during the elaboration of either a \vpackage declaration\v701. or a \vtask declaration\v901., this elaboration is abandoned; the next action depends on the nature of the declaration. (e) For a package declaration or a task declaration, that is a declarative item, the exception is raised again immediately after the declarative item in the enclosing declarative part or \vpackage specification\v701.. For the declaration of a library package, the execution of the main program is abandoned. An exception that is raised again (as in the above cases (a), (b), (c) and (e)) is said to be propagated, either by the execution of the subprogram or block statement, or by the elaboration of the package declaration, task declaration or package body. Example of an exception in the declarative part of a block statement (case (b)): \uprocedure\n P \uis\n ... \ubegin\n declare N : INTEGER := F; -- the function F may raise ERROR \ubegin\n ... \uexception\n \uwhen\n ERROR => -- handler E1 \uend\n ; ... \uexception\n \uwhen\n ERROR => -- handler E2 \uend\nP; -- if the exception ERROR is raised in the declaration of N, it is handled by E2 :1107 11.5 \uExceptions Raised During Task Communication\n An \vexception\v1100. can be propagated to a task communicating, or attempting to communicate, with another \vtask\v900.. An exception can also be propagated to a calling task if the exception is raised during a \vrendezvous\v905.. When a task calls an entry of another task, the \vexception TASKING_ERROR\v1101. is raised in the calling task, at the place of the call, if the called task is completed before accepting the \ventry call\v905. or is already completed at the time of the call. A rendezvous can be completed abnormally in two cases: (a) When an exception is raised within an \vaccept statement\v905., but not handled within an inner \vframe\v1102.. In this case, the execution of the accept statement is abandoned and the same exception is raised again immediately after the accept statement within the called task; the exception is also propagated to the calling task at the point of the entry call. (b) When the task containing the accept statement is completed abnormally as the result of an \vabort statement\v913.. In this case, the exception TASKING_ERROR is raised in the calling task at the point of the entry call. On the other hand, if a task issuing an entry call becomes abnormal (as the result of an abort statement) no exception is raised in the called task. If the rendezvous has not yet started, the entry call is cancelled. If the rendezvous is in progress, it completes normally, and the called task is unaffected. :1108 11.6 \uExceptions and Optimization\n The purpose of this section is to specify the conditions under which an implementation is allowed to perform certain actions either earlier or later than specified by other rules of the language. In general, when the language rules specify an order for certain actions (the canonical order), an implementation may only use an alternative order if it can guarantee that the effect of the program is not changed by the reordering. In particular, no \vexception\v1100. should arise for the execution of the reordered program if none arises for the execution of the program in the canonical order. When, on the other hand, the order of certain actions is not defined by the language, any order can be used by the implementation. (For example, the arguments of a \vpredefined operator\v411. can be evaluated in any order since the rules given in section 4.5 do not require a specific order of evaluation.) Additional freedom is left to an implementation for reordering actions involving predefined operations that are either predefined operators or \vbasic operations\v308. other than \vassignments\v502.. This freedom is left, as defined below, even in the case where the execution of these predefined operations may \vpropagate a (predefined) exception\v1104.: (a) For the purpose of establishing whether the same effect is obtained by the execution of certain actions in the canonical and in an alternative order, it can be assumed that none of the predefined operations invoked by these actions propagates a (predefined) exception, provided that the two following requirements are met by the alternative order: first, an operation must not be invoked in the alternative order if it is not invoked in the canonical order; second, for each operation, the innermost enclosing \vframe\v1102. or \vaccept\v905. \vstatement\v905. must be the same in the alternative order as in the canonical order, and the same \vexception handlers\v1102. must apply. (b) Within an expression, the association of operators with operands is specified by the syntax. However, for a sequence of predefined operators of the same precedence level (and in the absence of parentheses imposing a specific association), any association of operators with operands is allowed if it satisfies the following requirement: an integer result must be equal to that given by the canonical left-to-right order; a real result must belong to the result model interval defined for the canonical left-to-right order (see 4.5.7). Such a reordering is allowed even if it may remove an exception, or introduce a further predefined exception. Similarly, additional freedom is left to an implementation for the evaluation of numeric simple expressions. For the evaluation of a predefined operation, an implementation is allowed to use the operation of a type that has a range wider than that of the \vbase type\v305. of the operands, provided that this delivers the exact result (or a result within the declared \vaccuracy\v418., in the case of a \vreal type\v316.), even if some intermediate results lie outside the range of the base type. The \vexception\v1101. \vNUMERIC_ERROR\v1101. need not be raised in such a case. In particular, if the numeric expression is an operand of a predefined relational operator, the exception NUMERIC_ERROR need not be raised by the evaluation of the relation, provided that the correct BOOLEAN result is obtained. A preedefined operation need not be invoked at all, if its only possible effect is to propagate a predefined exception. Similarly, a predefined operation need not be invoked if the removal of subsequent operations by the above rule renders this invocation ineffective. \uNotes:\n Rule (b) applies to predefined operators but not to the short-circuit control forms. The expression SPEED < 300_000.0 can be replaced by TRUE if the value 300_000.0 lies outside the base type of SPEED, even though the implicit \vconversion\v419. of the numeric literal would raise the exception NUMERIC_ERROR. Example: declare N : INTEGER; \ubegin\n N := 0; -- (1) \ufor\n J \uin\n 1 .. 10 \uloop\n N := N + J**A(K); -- A and K are global variables \uend loop\n; PUT(N); \uexception\n \uwhen others\n => PUT("Some error arose"); PUT(N); \uend\n; The evaluation of A(K) may be performed before the loop, and possibly immediately before the assignment statement (1) even if this evaluation can raise an exception. Consequently, within the exception handler, the value of N is either the undefined initial value or a value later assigned. On the other hand, the evaluation of A(K) cannot be moved before begin since an exception would then be handled by a different handler. For this reason, the initialization of N in the declaration itself would exclude the possibility of having an undefined initial value of N in the handler. :1109 11.7 \uSuppressing Checks\n The presence of a SUPPRESS \vpragma\v210. gives permission to an implementation to omit certain run-time checks. The form of this pragma is as follows: pragma SUPPRESS(identifier [, [ON =>] name]); The \videntifier\v203. is that of the check that can be omitted. The name (if present) must be either a \vsimple name\v401. or an \vexpanded name\v404. and it must denote either an \vobject\v302., a \vtype\v305. or \vsubtype\v305., a \vtask unit\v900., or a \vgeneric unit\v1200.; alternatively the name can be a subprogram name, in which case it can stand for several visible overloaded \vsubprograms\v600.. A pragma SUPPRESS is only allowed immediately within a \vdeclarative part\v333. or immediately within a \vpackage specification\v701.. In the latter case, the only allowed form is with a name that denotes an entity (or several overloaded subprograms) declared immediately within the package specification. The permission to omit the given check extends from the place of the pragma to the end of the declarative region associated with the innermost enclosing \vblock statement\v507. or \vprogram unit\v600.. For a pragma given in a package specification, the permission extends to the end of the scope of the named entity. If the pragma includes a name, the permission to omit the given check is further restricted: it is given only for \voperations\v308. on the named object or on all objects of the base type of a named type or subtype; for calls of a named subprogram; for \vactivations\v903. of \vtasks\v900. of the named \vtask type\v901.; or for instantiations of the given generic unit. The following checks correspond to situations in which the \vexception\v1101. \vCONSTRAINT_ERROR\v1101. may be raised; for these checks, the name (if present) must denote either an object or a type. ACCESS_CHECK When accessing a selected component, an \vindexed\v402. \vcomponent\v402., a \vslice\v403., or an \vattribute\v405., of an object \vdesignated\v330. by an \vaccess value\v330., check that the access value is not null. DISCRIMINANT_CHECK Check that a \vdiscriminant\v326. of a composite value has the value imposed by a \vdiscriminant constraint\v327.. Also, when accessing a \vrecord component\v325., check that it exists for the current discriminant values. INDEX_CHECK Check that the bounds of an \varray\v321. value are equal to the corresponding bounds of an \vindex constraint\v322.. Also, when accessing a \vcomponent of an array\v321. object, check for each \vdimension\v321. that the given index value belongs to the range defined by the bounds of the array object. Also, when accessing a slice of an array object, check that the given \vdiscrete range\v321. is \vcompatible\v307. with the range defined by the bounds of the array object. LENGTH_CHECK Check that there is a matching component for each component of an array, in the case of array assignments, type conversions, and logical operators for arrays of boolean components. RANGE_CHECK Check that a value satisfies a \vrange constraint\v310.. Also, for the \velaboration\v301. of a subtype indication, check that the \vconstraint\v305. (if present) is compatible with the \vtype mark\v307.. Also, for an \vaggregate\v407., check that an \vindex\v321. or discriminant value belongs to the corresponding subtype. Finally, check for any constraint checks performed by a \vgeneric\v1206. \vinstantiation\v1206.. The following checks correspond to situations in which the \vexception\v1101. \vNUMERIC_ERROR\v1101. is raised. The only allowed names in the corresponding pragmas are names of \vnumeric types\v310.. DIVISION_CHECK Check that the second operand is not zero for the operations /, rem and mod. OVERFLOW_CHECK Check that the result of a \vnumeric operation\v315. does not overflow. The following check corresponds to situations in which the \vexception\v1101. \vPROGRAM_ERROR\v1101. is raised. The only allowed names in the corresponding pragmas are names denoting task units, generic units, or subprograms. ELABORATION_CHECK When either a subprogram is called, a task activation is accomplished, or a generic instantiation is elaborated, check that the body of the corresponding unit has already been elaborated. The following check corresponds to situations in which the exception STORAGE_ERROR is raised. The only allowed names in the corresponding pragmas are names denoting \vaccess types\v330., task units, or subprograms. STORAGE_CHECK Check that execution of an \vallocator\v421. does not require more space than is available for a \vcollection\v330.. Check that the space available for a task or subprogram has not been exceeded. If an \verror situation\v1100. arises in the absence of the corresponding run-time checks, the execution of the program is \verroneous\v108. (the results are not defined by the language). \uExamples:\n \upragma \nSUPPRESS(RANGE_CHECK); \upragma \nSUPPRESS(INDEX_CHECK, ON => TABLE); \uNotes:\n For certain implementations, it may be impossible or too costly to suppress certain checks. The corresponding SUPPRESS pragma can be ignored. Hence, the occurrence of such a pragma within a given unit does not guarantee that the corresponding exception will not arise; the exceptions may also be propagated by called units. :1200 12. \uGeneric Units\n A generic unit is a \vprogram unit\v600. that is either a \vgeneric subprogram\v1201. or a \vgeneric package\v1201.. A generic unit is a template, which is parameterized or not, and from which corresponding (nongeneric) \vsubprograms\v600. or \vpackages\v700. can be obtained. The resulting program units are said to be \vinstances\v1206. of the original generic unit. A generic unit is declared by a \vgeneric declaration\v1201.. This form of \vdeclaration\v301. has a \vgeneric formal part\v1201. declaring any \vgeneric formal\v1201. \vparameters\v1201.. An instance of a generic unit is obtained as the result of a \vgeneric instantiation\v1206. with appropriate \vgeneric actual parameters\v1206. for the generic formal parameters. An instance of a generic subprogram is a subprogram. An instance of a generic package is a package. Generic units are templates. As templates they do not have the properties that are specific to their nongeneric counterparts. For example, a generic subprogram can be instantiated but it cannot be called. In contrast, the instance of a generic subprogram is a nongeneric subprogram; hence, this instance can be called but it cannot be used to produce further instances. More details: 12.1 \vGeneric Declarations\v1201. 12.2 \vGeneric Bodies\v1205. 12.3 \vGeneric Instantiation\v1206. 12.4 \vExample of a Generic Package\v1213. :1201 12.1 \uGeneric Declarations\n A generic \vdeclaration\v301. declares a generic unit, which is either a generic subprogram or a generic package. A generic declaration includes a generic formal part declaring any generic formal parameters. A generic formal parameter can be an \vobject\v302.; alternatively (unlike a \vparameter of a\v602. \vsubprogram\v602.), it can be a \vtype\v305. or a \vsubprogram\v600.. generic_declaration ::= generic_specification; generic_specification ::= generic_formal_part \vsubprogram_specification\v601. | generic_formal_part \vpackage_specification\v701. generic_formal_part ::= generic {generic_parameter_declaration} generic_parameter_declaration ::= \videntifier_list\v302. : [\uin \n[\uout\n]] type_mark [:= expression]; | \utype \nidentifier \uis \ngeneric_type_definition; | \vprivate_type_declaration\v704. | \uwith \nsubprogram_specification [\uis \nname]; | \uwith \nsubprogram_specification [\uis \n<>]; generic_type_definition ::= (<>) | \urange \n<> | \udigits \n<> | \udelta \n<> | \varray_type_definition\v321. | \vaccess_type_definition\v330. The terms generic formal object (or simply, formal object), generic formal type (or simply, formal type), and generic formal subprogram (or simply, formal subprogram) are used to refer to corresponding generic formal parameters. The only form of \vsubtype indication\v307. allowed within a generic formal part is a \vtype mark\v307. (that is, the subtype indication must not include an explicit \vconstraint\v305.). The \vdesignator\v601. of a generic subprogram must be an \videntifier\v203.. Outside the specification and body of a generic unit, the \vname\v401. of this program unit denotes the generic unit. In contrast, within the declarative region associated with a generic subprogram, the name of this program unit denotes the subprogram obtained by the current instantiation of the generic unit. Similarly, within the declarative region associated with a generic package, the name of this program unit denotes the package obtained by the current instantiation. The elaboration of a generic declaration has no other effect. Examples of generic formal parts: generic -- parameterless generic SIZE : NATURAL; -- formal object generic LENGTH : INTEGER := 200; -- formal object with a default expression AREA : INTEGER := LENGTH*LENGTH; -- formal object with a default expression generic \utype \nITEM \uis private\n; -- formal type \utype \nINDEX \uis\n (<>); -- formal type \utype \nROW \uis array\n(INDEX \urange \n<>) \uof \nITEM; -- formal type \uwith\n \vfunction\v609. "<"(X, Y : ITEM) \ureturn\n BOOLEAN; -- formal subprogram Examples of generic declarations declaring generic subprograms: generic \utype\n ELEM \uis private\n; \vprocedure\v601. EXCHANGE(U, V : \uin out\n ELEM); generic \utype\n ITEM \uis private\n; \uwith function\n "*"(U, V : ITEM) \ureturn\n ITEM \uis\n <>; \ufunction\n SQUARING(X : ITEM) \ureturn\n ITEM; Example of a generic declaration declaring a generic package: generic \utype\n ITEM \uis private\n; \utype\n VECTOR \uis array\n (POSITIVE \urange\n <>) \uof\n ITEM; \uwith function\n SUM(X, Y : ITEM) \ureturn\n ITEM; \upackage\n ON_VECTORS \ui\ns \ufunction\n SUM (A, B : VECTOR) \ureturn\n VECTOR; \ufunction\n SIGMA(A : VECTOR) \ureturn\n ITEM; LENGTH_ERROR : \uexception\n; \uend\n; \uNotes:\n Within a generic subprogram, the name of this program unit acts as the name of a subprogram. Hence this name can be \voverloaded\v610., and it can appear in a recursive call of the current instantiation. For the same reason, this name cannot appear after the \vreserved word\v211. new in a (recursive) \vgeneric\v1206. \vinstantiation\v1206.. An \vexpression\v410. that occurs in a generic formal part is either the default expression for a generic formal object of mode in, or a constituent of an entry name given as default name for a formal subprogram, or the default expression for a parameter of a formal subprogram. Default expressions for generic formal objects and default names for formal subprograms are only evaluated for generic instantiations that use such defaults. Default expressions for parameters of formal subprograms are only evaluated for calls of the formal subprograms that use such defaults. (The usual visibility rules apply to any name used in a default expression: the denoted \ventity\v301. must therefore be visible at the place of the expression.) Neither generic formal parameters nor their \vattributes\v405. are allowed constituents of \vstatic expressions\v422.. More details: 12.1.1 \vGeneric Formal Objects\v1202. 12.1.2 \vGeneric Formal Types\v1203. 12.1.3 \vGeneric Formal Subprograms\v1204. :1202 12.1.1 \uGeneric Formal Objects\n The first form of \vgeneric parameter declaration\v1201. declares \vgeneric formal\v1201. \vobjects\v1201.. The type of a generic formal object is the \vbase type\v305. of the type denoted by the \vtype mark\v307. given in the generic parameter declaration. A generic parameter declaration with several \videntifiers\v203. is equivalent to a sequence of single generic parameter declarations, as explained in section A generic formal object has a \vmode\v601. that is either in or in out. In the absence of an explicit mode indication in a generic parameter declaration, the mode in is assumed; otherwise the mode is the one indicated. If a generic parameter declaration ends with an expression, the expression is the default expression of the \vgeneric formal parameter\v1201.. A default expression is only allowed if the mode is in (whether this mode is indicated explicitly or implicitly). The type of a default expression must be that of the corresponding generic formal parameter. A generic formal object of mode in is a constant whose value is a copy of the value supplied as the \vmatching generic actual parameter\v1206. in a \vgeneric\v1206. \vinstantiation\v1206., as described in section 12.3. The type of a generic formal object of mode in must not be a \vlimited type\v708.; the \vsubtype\v305. of such a generic formal object is the subtype denoted by the type mark given in the generic parameter declaration. A generic formal object of mode in out is a \vvariable\v303. and denotes the \vobject\v302. supplied as the matching \vgeneric actual parameter\v1206. in a generic instantiation, as described in section 12.3. The \vconstraints\v305. that apply to the generic formal object are those of the corresponding generic actual parameter. Note: The constraints that apply to a generic formal object of mode in out are those of the corresponding generic actual parameter (not those implied by the type mark that appears in the generic parameter declaration). Whenever possible (to avoid confusion) it is recommended that the \vname\v401. of a base type be used for the \vdeclaration\v301. of such a formal object. If, however, the base type is \vanonymous\v306., it is recommended that the subtype name defined by the \vtype declaration\v305. for the base type be used. :1203 12.1.2 \uGeneric Formal Types\n A \vgeneric parameter declaration\v1201. that includes a \vgeneric type definition\v1201. or a \vprivate type declaration\v704. declares a \vgeneric formal type\v1201.. A generic formal type denotes the subtype supplied as the corresponding actual parameter in a generic instantiation, as described in 12.3(d). However, within a generic unit, a generic formal type is considered as being distinct from all other (formal or nonformal) types. The form of \vconstraint\v305. applicable to a formal type in a \vsubtype indication\v307. depends on the \vclass of the type\v305. as for a nonformal type. The only form of \vdiscrete range\v321. that is allowed within the \vdeclaration\v301. of a generic formal (constrained) array type is a \vtype mark\v307.. The \vdiscriminant part\v326. of a generic formal private type must not include a default expression for a discriminant. (Consequently, a variable that is declared by an object declaration must be constrained if its type is a generic formal type with discriminants.) Within the declaration and \vbody of a generic unit\v1205., the \voperations\v305. available for values of a generic formal type (apart from any additional operation specified by a \vgeneric formal subprogram\v1204.) are determined by the generic parameter declaration for the formal type: (a) For a private type declaration, the available operations are those defined in section 7.4.2 (in particular, \vassignment\v502., \vequality\v413., and \vinequality\v413. are available for a private type unless it is limited). (b) For an \varray type definition\v321., the available operations are those defined in section 3.6.2 (for example, they include the formation of \vindexed components\v402. and \vslices\v403.). (c) For an \vaccess type definition\v330., the available operations are those defined in section 3.8.2 (for example, \vallocators\v421. can be used). The four forms of generic type definition in which a box appears (that is, the compound delimiter <>) correspond to the following major forms of \vscalar type\v310.: (d) \vDiscrete types\v310.: (<>) The available operations are the operations common to \venumeration\v311. and \vinteger types\v314.; these are defined in section 3.5.5. (e) Integer types: range <> The available operations are the operations of integer types defined in section 3.5.5. (f) \vFloating point types\v317.: digits <> The available operations are those defined in section 3.5.8. (g) \vFixed point types\v319.: delta <> The available operations are those defined in section 3.5.10. In all of the above cases (a) through (f), each operation implicitly associated with a formal type (that is, other than an operation specified by a formal subprogram) is implicitly declared at the place of the declaration of the formal type. The same holds for a formal fixed point type, except for the \vmultiplying operators\v411. that deliver a result of the type \vuniversal_fixed\v319. (see 4.5.5), since these special \voperators\v411. are declared in the \vpackage STANDARD\v806.. For an \vinstantiation\v1206. of the generic unit, each of these operations is the corresponding basic operation or predefined operator of the matching actual type. For an operator, this rule applies even if the operator has been redefined for the actual type or for some \vparent type\v309. of the actual type. Examples of generic formal types: \utype\n ITEM \uis private\n; \utype\n BUFFER(LENGTH : NATURAL) \uis\n \vlimited private\v708.; \utype\n ENUM \uis\n (<>); \utype\n INT \uis range\n <>; \utype\n ANGLE \uis delta\n <>; \utype\n MASS \uis digits\n <>; \utype\n TABLE \uis array\n (ENUM) \uof\n ITEM; Example of a \vgeneric formal part\v1201. declaring a formal integer type: generic \utype\n RANK \uis range\n <>; FIRST : RANK := RANK'FIRST; SECOND : RANK := FIRST + 1; -- the operator "+" of the type RANK :1204 12.1.3 \uGeneric Formal Subprograms\n A \vgeneric parameter declaration\v1201. that includes a \vsubprogram specification\v601. declares a \vgeneric formal subprogram\v1201.. Two alternative forms of defaults can be specified in the declaration of a generic formal subprogram. In these forms, the subprogram specification is followed by the \vreserved word\v211. is and either a box or the name of a \vsubprogram\v600. or entry. The matching rules for these defaults are explained in section 12.3.6. A generic formal subprogram denotes the subprogram, enumeration literal, or entry supplied as the corresponding \vgeneric actual parameter\v1206. in a \vgeneric\v1206. \vinstantiation\v1206., as described in section 12.3(f). Examples of generic formal subprograms: \uwith function\n INCREASE(X : INTEGER) \ureturn\n INTEGER; \uwith function\n SUM(X, Y : ITEM) \ureturn\n ITEM; \uwith function\n "+"(X, Y : ITEM) \ureturn\n ITEM \uis\n <>; \uwith function\n IMAGE(X : ENUM) \ureturn\n STRING \uis\n ENUM'IMAGE; \uwith procedure\n UPDATE \uis\n DEFAULT_UPDATE; \uNotes:\n The \vconstraints\v305. that apply to a parameter of a formal subprogram are those of the corresponding parameter in the specification of the matching actual subprogram (not those implied by the corresponding \vtype mark\v307. in the specification of the formal subprogram). A similar remark applies to the result of a function. Whenever possible (to avoid confusion), it is recommended that the name of a \vbase type\v305. be used rather than the name of a \vsubtype\v307. in any declaration of a formal subprogram. If, however, the base type is \vanonymous\v306., it is recommended that the subtype name defined by the \vtype\v305. declaration be used. The type specified for a formal parameter of a generic formal subprogram can be any visible type, including a generic formal type of the same generic formal part. :1205 12.2 \uGeneric Bodies\n The \vbody\v333. of a \vgeneric subprogram\v1201. or \vgeneric package\v1201. is a template for the bodies of the corresponding \vsubprograms\v600. or \vpackages\v700. obtained by \vgeneric\v1206. \vinstantiations\v1206.. The syntax of a \vgeneric body\v1201. is identical to that of a nongeneric body. For each declaration of a generic subprogram, there must be a corresponding body. The \velaboration\v333. of a generic body has no other effect than to establish that the body can from then on be used as the template for obtaining the corresponding \vinstances\v1206.. Example of a generic procedure body: procedure EXCHANGE(U, V : in out ELEM) is -- see example in 12.1 T : ELEM; -- the generic formal type \ubegin\n T := U; U := V; V := T; \uend\n EXCHANGE; Example of a generic function body: \ufunction\n SQUARING(X : ITEM) \ureturn\n ITEM \uis\n -- see example in 12.1 \ubegin\n \ureturn\n X*X; -- the formal operator "*" \uend\n; Example of a generic package body: \vpackage body\v701. ON_VECTORS \uis\n -- see example in 12.1 \ufunction\n SUM(A, B : VECTOR) \ureturn\n VECTOR \uis\n RESULT : VECTOR(A'RANGE); -- the formal type VECTOR BIAS : constant INTEGER := B'FIRST - A'FIRST; \ubegin\n \uif\n A'LENGTH /= B'LENGTH \uthen\n \uraise\n LENGTH_ERROR; \uend if\n; \ufor\n N \uin\n A'RANGE \uloop\n RESULT(N) := SUM(A(N), B(N + BIAS)); -- the formal \uend loop\n; function SUM \ureturn\n RESULT; \uend\n; \ufunction\n SIGMA(A : VECTOR) \ureturn\n ITEM \uis\n TOTAL : ITEM := A(A'FIRST); -- the formal type ITEM \ubegin\n \ufor\n N \uin\n A'FIRST + 1 .. A'LAST \uloop\n TOTAL := SUM(TOTAL, A(N)); -- the formal function SUM \uend loop\n; \ureturn\n TOTAL; \uend\n; \uend\n; :1206 12.3 \uGeneric Instantiation\n An instance of a generic unit is declared by a generic instantiation. generic_instantiation ::= \upackage\n \videntifier\v203. \uis\n \unew\n generic_package_name [generic_actual_part]; | \uprocedure\n identifier \uis\n \unew\n generic_procedure_name [generic_actual_part]; | \ufunction\n designator \uis\n \unew\n generic_function_name [generic_actual_part]; generic_actual_part ::= (generic_association {, generic_association}) generic_association ::= [\vgeneric_formal_parameter\v1201. =>] generic_actual_parameter generic_formal_parameter ::= parameter_simple_name | \voperator_symbol\v601. generic_actual_parameter ::= \vexpression\v410. | variable_name | \vsubprogram_name\v601. | \ventry_name\v905. | \vtype_mark\v307. An explicit generic actual parameter must be supplied for each generic formal parameter, unless the corresponding \vgeneric parameter declaration\v1201. specifies that a default can be used. Generic associations can be either positional or named in the same manner as parameter associations of \vsubprogram calls\v606.. If two or more formal subprograms have the same \vdesignator\v601., then named associations are not allowed for the corresponding generic parameters. Each generic actual parameter must match the corresponding generic formal parameter. An expression can match a formal object of \vmode in\v1202.; a variable name can match a formal object of \vmode in out\v1202.; a subprogram name or an entry name can match a formal subprogram; a type mark can match a formal type. The detailed rules defining the allowed matches are given in sections 12.3.1 to 12.3.6; these are the only allowed matches. The instance is a copy of the generic unit, apart from the generic formal part; thus the instance of a generic package is a \vpackage\v700., that of a generic procedure is a procedure, and that of a generic function is a function. For each occurrence, within the generic unit, of a \vname\v401. that denotes a given \ventity\v301., the following list defines which entity is denoted by the corresponding occurrence within the instance. (a) For a name that denotes the generic unit: The corresponding occurrence denotes the instance. (b) For a name that denotes a \vgeneric formal object\v1201. of mode in: The corresponding name denotes a constant whose value is a copy of the value of the associated generic actual parameter. (c) For a name that denotes a generic formal object of mode in out: The corresponding name denotes the \vvariable\v303. named by the associated generic actual parameter. (d) For a name that denotes a \vgeneric formal type\v1201.: The corresponding name denotes the subtype named by the associated generic actual parameter (the actual subtype). (e) For a name that denotes a \vdiscriminant\v326. of a generic formal type: The corresponding name denotes the corresponding discriminant (there must be one) of the actual type associated with the generic formal type. (f) For a name that denotes a \vgeneric formal subprogram\v1201.: The corresponding name denotes the \vsubprogram\v600., enumeration literal, or entry named by the associated generic actual parameter (the actual subprogram). (g) For a name that denotes a formal parameter of a generic formal subprogram: The corresponding name denotes the corresponding formal parameter of the actual subprogram associated with the formal subprogram. (h) For a name that denotes a local entity declared within the generic unit: The corresponding name denotes the entity declared by the corresponding \vlocal declaration\v801. within the instance. (i) For a name that denotes a global entity declared outside of the generic unit: The corresponding name denotes the same global entity. Similar rules apply to operators and basic \voperations\v305.: in particular, formal operators follow a rule similar to rule (f), local operations follow a rule similar to rule (h), and operations for global types follow a rule similar to rule (i). In addition, if within the generic unit a predefined operator or basic operation of a formal type is used, then within the instance the corresponding occurrence refers to the corresponding predefined operation of the actual type associated with the formal type. The above rules apply also to any type mark or (default) expression given within the generic formal part of the generic unit. For the \velaboration\v301. of a generic instantiation, each expression supplied as an explicit generic actual parameter is first evaluated, as well as each expression that appears as a constituent of a variable name or entry name supplied as an explicit generic actual parameter; these \vevaluations\v411. proceed in some order that is not defined by the language. Then, for each omitted generic association (if any), the corresponding default expression or default name is evaluated; such evaluations are performed in the order of the generic parameter declarations. Finally, the implicitly generated instance is elaborated. The elaboration of a generic instantiation may also involve certain constraint checks as described in later subsections. Recursive generic instantiation is not allowed in the following sense: if a given generic unit includes an instantiation of a second generic unit, then the instance generated by this instantiation must not include an instance of the first generic unit (whether this instance is generated directly, or indirectly by intermediate instantiations). Examples of generic instantiations (see 12.1): \uprocedure\n SWAP \uis new\n EXCHANGE(ELEM => INTEGER); \uprocedure\n SWAP \uis new\n EXCHANGE(CHARACTER); -- SWAP is \voverloaded\v610. \ufunction\n SQUARE \uis new\n SQUARING(INTEGER); -- "*" of INTEGER used by default \ufunction\n SQUARE \uis new\n SQUARING(ITEM => MATRIX, "*" => MATRIX_PRODUCT); \ufunction\n SQUARE \uis new\n SQUARING(MATRIX, MATRIX_PRODUCT); -- same as previous \upackage\n INT_VECTORS \uis new\n ON_VECTORS(INTEGER, TABLE, "+"); Examples of uses of instantiated units: SWAP(A, B); A := SQUARE(A); T : TABLE(1 .. 5) := (10, 20, 30, 40, 50); N : INTEGER := INT_VECTORS.SIGMA(T); -- 150 (see 12.2 for the body of SIGMA) \uuse\n INT_VECTORS; M : INTEGER := SIGMA(T); -- 150 \uNotes:\n Omission of a generic actual parameter is only allowed if a corresponding default exists. If default expressions or default names (other than \vsimple\v401. \vnames\v401.) are used, they are evaluated in the order in which the corresponding generic formal parameters are declared. If two overloaded subprograms declared in a generic package specification differ only by the (formal) type of their parameters and results, then there exist legal instantiations for which all calls of these subprograms from outside the instance are ambiguous. For example: generic \utype\n A \uis\n (<>); \utype\n B \uis private\n; \upackage\n G \uis\n \ufunction\n NEXT(X : A) \ureturn\n A; \ufunction\n NEXT(X : B) \ureturn\n B; \uend\n; \upackage\n P \uis new\n G(A => BOOLEAN, B => BOOLEAN); -- calls of P.NEXT are ambiguous More details: 12.3.1 \vMatching Rules for Formal Objects\v1207. 12.3.2 \vMatching Rules for Formal Private Types\v1208. 12.3.3 \vMatching Rules for Formal Scalar Types\v1209. 12.3.4 \vMatching Rules for Formal Array Types\v1210. 12.3.5 \vMatching Rules for Formal Access Types\v1211. 12.3.6 \vMatching Rules for Formal Subprograms\v1212. :1207 12.3.1 \uMatching Rules for Formal Objects\n A \vgeneric formal parameter\v1201. of \vmode in\v1202. of a given \vtype\v305. is matched by an \vexpression\v410. of the same type. If a \vgeneric unit\v1201. has a \vgeneric formal object\v1202. of mode in, a check is made that the value of the expression belongs to the subtype denoted by the \vtype mark\v307., as for an explicit constant declaration (see 3.2.1). The \vexception CONSTRAINT_ERROR\v1101. is raised if this check fails. A generic formal parameter of \vmode in out\v1202. of a given type is matched by the \vname\v401. of a \vvariable\v303. of the same type. The variable must not be a \vformal\v601. \vparameter\v601. of \vmode out\v602. or a \vsubcomponent\v305. thereof. The name must denote a variable for which renaming is allowed (see 8.5). \uNotes:\n The type of a \vgeneric actual parameter\v1206. of mode in must not be a \vlimited\v708. \vtype\v708.. The \vconstraints\v305. that apply to a generic formal parameter of mode in out are those of the corresponding generic actual parameter (see 12.1.1). :1208 12.3.2 \uMatching Rules for Formal Private Types\n A generic formal \vprivate type\v704. is matched by any \vtype\v305. or \vsubtype\v305. (the actual subtype) that satisfies the following conditions: - If the formal type is not limited, the actual type must not be a \vlimited type\v708.. (If, on the other hand, the formal type is limited, no such condition is imposed on the corresponding actual type, which can be limited or not limited.) - If the formal type has a \vdiscriminant part\v326., the actual type must be a type with the same number of \vdiscriminants\v326.; the type of a discriminant that appears at a given position in the discriminant part of the actual type must be the same as the type of the discriminant that appears at the same position in the discriminant part of the formal type; and the actual subtype must be unconstrained. (If, on the other hand, the formal type has no discriminants, the actual type is allowed to have discriminants.) Furthermore, consider any occurrence of the \vname\v401. of the formal type at a place where this name is used as an unconstrained \vsubtype indication\v307.. The actual subtype must not be an \vunconstrained array type\v321. or an unconstrained \vtype with discriminants\v305., if any of these occurrences is at a place where either a \vconstraint\v305. or \vdefault discriminants\v326. would be required for an \varray\v321. \vtype\v321. or for a type with discriminants (see 3.6.1 and 3.7.2). The same restriction applies to occurrences of the name of a subtype of the formal type, and to occurrences of the name of any type or subtype derived, directly or indirectly, from the formal type. If a generic unit has a formal private type with discriminants, the \velaboration\v333. of a corresponding \vgeneric instantiation\v1206. checks that the subtype of each discriminant of the actual type is the same as the subtype of the corresponding discriminant of the formal type. The \vexception\v1101. \vCONSTRAINT_ERROR\v1101. is raised if this check fails. :1209 12.3.3 \uMatching Rules for Formal Scalar Types\n A \vgeneric formal type\v1203. defined by (<>) is matched by any \vdiscrete\v310. subtype (that is, any \venumeration\v311. or \vinteger\v314. subtype). A generic formal type defined by range <> is matched by any integer subtype. A generic formal type defined by digits <> is matched by any \vfloating point\v317. subtype. A generic formal type defined by delta <> is matched by any \vfixed point\v319. subtype. No other matches are possible for these generic formal types. :1210 12.3.4 \uMatching Rules for Formal Array Types\n A formal \varray type\v321. is matched by an actual array \vsubtype\v305. that satisfies the following conditions: - The formal array type and the actual array type must have the same dimensionality; the \vformal type\v1201. and the actual subtype must be either both \vconstrained\v321. or both \vunconstrained\v321.. - For each \vindex\v321. position, the index type must be the same for the actual array type as for the formal array type. - The component type must be the same for the actual array type as for the formal array type. If the component type is other than a scalar type, then the component subtypes must be either both constrained or both unconstrained. If a generic unit has a formal array type, the \velaboration\v333. of a corresponding instantiation checks that the \vconstraints\v305. (if any) on the component type are the same for the actual array type as for the formal array type, and likewise that for any given index position the index subtypes or the discrete ranges have the same bounds. The \vexception\v1101. \vCONSTRAINT_ERROR\v1101. is raised if this check fails. Example: -- given the generic package generic \utype\n ITEM i\us privat\ne; \utype\n INDEX \uis\n (<>); \utype\n VECTOR \uis array\n (INDEX \urange\n <>) \uof\n ITEM; \utype\n TABLE \uis array\n (INDEX) \uof\n ITEM; \upackage\n P \uis\n ... \uend\n; -- and the types \utype\n MIX \uis array\n (COLOR \urange\n <>) \uof\n BOOLEAN; \utype\n OPTION \uis array\n (COLOR) \uof\n BOOLEAN; -- then MIX can match VECTOR and OPTION can match TABLE \upackage\n R \uis new\n P(ITEM => BOOLEAN, INDEX => COLOR, VECTOR => MIX, TABLE => OPTION); -- Note that MIX cannot match TABLE and OPTION cannot match VECTOR Note: For the above rules, if any of the index or component types of the formal array type is itself a formal type, then within the instance its name denotes the corresponding actual subtype (see 12.3(d)). :1211 12.3.5 \uMatching Rules for Formal Access Types\n A formal \vaccess type\v330. is matched by an actual access subtype if the type of the designated \vobjects\v302. is the same for the actual type as for the formal type. If the designated type is other than a scalar type, then the designated subtypes must be either both constrained or both unconstrained. If a generic unit has a formal access type, the \velaboration\v333. of a corresponding instantiation checks that any \vconstraints\v305. on the designated objects are the same for the actual access subtype as for the formal access type. The \vexception CONSTRAINT_ERROR\v1101. is raised if this check fails. Example: -- the formal types of the generic package generic \utype\n NODE \uis private\n; \utype\n LINK \uis access\n NODE; \upackage\n P \uis\n ... \uend\n; -- can be matched by the actual types \utype\n CAR; \utype\n CAR_NAME \uis access\n CAR; \utype\n CAR \uis\n \urecord\n PRED, SUCC : CAR_NAME; NUMBER : LICENSE_NUMBER; OWNER : PERSON; \uend record\n; -- in the following \vgeneric instantiation\v1206. \upackage\n R \uis new\n P(NODE => CAR, LINK => CAR_NAME); Note: For the above rules, if the designated type is itself a formal type, then within the instance its name denotes the corresponding actual subtype (see 12.3(d)). :1212 12.3.6 \uMatching Rules for Formal Subprograms\n A formal \vsubprogram\v600. is matched by an actual subprogram, enumeration literal, or \ventry\v905. if both have the same \vparameter and result type profile\v603. (see 6.6); in addition, parameter modes must be identical for formal parameters that are at the same parameter position. If a generic unit has a default subprogram specified by a \vname\v401., this name must denote a subprogram, an enumeration literal, or an entry, that matches the formal subprogram (in the above sense). The evaluation of the default name takes place during the elaboration of each instantiation that uses the default, as defined in section 12.3. If a generic unit has a default subprogram specified by a box, the corresponding actual parameter can be omitted if a subprogram, enumeration literal, or entry matching the formal subprogram, and with the same \vdesignator\v601. as the formal subprogram, is directly visible at the place of the \vgeneric instantiation\v1206.; this subprogram, enumeration literal, or entry is then used by default (there must be exactly one subprogram, enumeration literal, or entry satisfying the previous conditions). Example: -- given the generic function specification generic \utype\n ITEM \uis private\n; \uwith function\n "*" (U, V : ITEM) \ureturn\n ITEM \uis\n <>; \vfunction\v609. SQUARING(X : ITEM) \ureturn\n ITEM; -- and the function \ufunction\n MATRIX_PRODUCT(A, B : MATRIX) \ureturn\n MATRIX; -- the following instantiation is possible \ufunction\n SQUARE \uis new\n SQUARING(MATRIX, MATRIX_PRODUCT); -- the following instantiations are equivalent \ufunction\n SQUARE \uis new\n SQUARING(ITEM => INTEGER, "*" => "*"); \ufunction\n SQUARE \uis new\n SQUARING(INTEGER, "*"); \ufunction\n SQUARE \uis new\n SQUARING(INTEGER); \uNotes:\n The matching rules for formal subprograms state requirements that are similar to those applying to subprogram renaming declarations (see 8.5). In particular, the name of a parameter of the formal subprogram need not be the same as that of the corresponding parameter of the actual subprogram; similarly, for these parameters, default expressions need not correspond. A formal subprogram is matched by an \vattribute\v405. of a type if the attribute is a function with a matching specification. An enumeration literal of a given type matches a parameterless formal function whose result type is the given type. :1213 12.4 \uExample of a Generic Package\n The following example provides a possible formulation of stacks by means of a generic package. The size of each stack and the type of the stack elements are provided as generic parameters. generic SIZE : POSITIVE; \utype\n ITEM \uis private\n; \upackage\n STACK \uis\n \uprocedure\n PUSH(E : \uin\n ITEM); \uprocedure\n POP (E : \uout\n ITEM); OVERFLOW, UNDERFLOW : \uexception\n; \uend\n STACK; \upackage body\n STACK \uis\n \utype\n TABLE \uis array\n (POSITIVE \urange\n <>) \uof\n ITEM; SPACE : TABLE(1 .. SIZE); INDEX : NATURAL := 0; \uprocedure\n PUSH(E : \uin\n ITEM) \uis\n \ubegi\nn \uif\n INDEX >= SIZE \uthen\n \uraise\n OVERFLOW; \uend if\n; INDEX := INDEX + 1; SPACE(INDEX) := E; \uend\n PUSH; \uprocedure\n POP(E : \uout\n ITEM) \uis\n \ubegin\n \uif\n INDEX = 0 \uthen\n \uraise\n UNDERFLOW; \uend if\n; E := SPACE(INDEX); INDEX := INDEX - 1; \uend\n POP; \uend\n STACK; Instances of this generic package can be obtained as follows: \upackage\n STACK_INT \uis new\n STACK(SIZE => 200, ITEM => INTEGER); \upackage\n STACK_BOOL \uis new\n STACK(100, BOOLEAN); Thereafter, the procedures of the instantiated packages can be called as follows: STACK_INT.PUSH(N); STACK_BOOL.PUSH(TRUE); Alternatively, a generic formulation of the type STACK can be given as follows (package body omitted): generic \utype\n ITEM \uis private\n; \upackage\n ON_STACKS \uis\n \utype\n STACK(SIZE : POSITIVE) \uis limited private\n; \uprocedure\n PUSH(S : \uin out\n STACK; E : in ITEM); \uprocedure\n POP (S : \uin out\n STACK; E : out ITEM); OVERFLOW, UNDERFLOW : \uexception\n; \uprivate\n \utype\n TABLE \uis array\n (POSITIVE \urange\n <>) \uof\n ITEM; \utype\n STACK(SIZE : POSITIVE) \uis\n \urecord\n SPACE : TABLE(1 .. SIZE); INDEX : NATURAL := 0; \uend record\n; \uend\n; In order to use such a package, an instantiation must be created and thereafter stacks of the corresponding type can be declared: declare \upackage\n STACK_REAL \uis new\n ON_STACKS(REAL); \uuse\n STACK_REAL; S : STACK(100) \ubegin\n ... PUSH(S, 2.54); ... \uend\n; :1300 13. \uRepresentation Clauses and Implementation-Dependent Features\n This chapter describes representation clauses, certain implementation- dependent features, and other features that are used in system programming. More details: 13.1 \vRepresentation Clauses\v1301. 13.2 \vLength Clause\v1302. 13.3 \vEnumeration Representation Clauses\v1303. 13.4 \vRecord Representation Clauses\v1304. 13.5 \vAddress Clauses\v1305. 13.6 \vChange of Representation\v1307. 13.7 \vThe Package System\v1308. 13.8 \vMachine Code Insertions\v1312. 13.9 \vInterface to other Languages\v1313. 13.10 \vUnchecked Programming\v1314. :1301 13.1 \uRepresentation Clauses\n Representation clauses specify how the \vtypes\v305. of the language are to be mapped onto the underlying machine. They can be provided to give more efficient representation or to interface with features that are outside the domain of the language (for example, peripheral hardware). representation_clause ::= type_representation_clause | address_clause type_representation_clause ::= \vlength_clause\v1302. | \venumeration_representation_clause\v1303. |\vrecord_representation_clause\v1304. A type representation clause applies either to a type or to a first \vnamed\v401. \vsubtype\v305. (that is, to a \vsubtype declared\v307. by a type \vdeclaration\v301., the base type being therefore anonymous). Such a representation clause applies to all \vobjects\v302. that have this type or this first named subtype. At most one enumeration or record representation clause is \vallowed\v108. for a given type: an enumeration representation clause is only allowed for an enumeration type; a record representation clause, only for a record type. (On the other hand, more than one length clause can be provided for a given type; moreover, both a length clause and an enumeration or record representation clause can be provided.) A length clause is the only form of representation clause allowed for a \vtype derived\v309. from a \vparent type\v309. that has (user-defined) \vderivable\v310. \vsubprograms\310.. An \vaddress clause\v1305. applies either to an object; to a \vsubprogram\v600., \vpackage\v700., or \vtask unit\v900.; or to an \ventry\v905.. At most one address clause is allowed for any of these entities. A representation clause and declaration of the \ventity\v301. to which the clause applies \vmust\v108. both \voccur immediately within\v801. the same \vdeclarative\v333. \vpart\v333., \vpackage specification\v701., or \vtask specification\v901.; the declaration must occur before the clause. In the absence of a representation clause for a given declaration, a default representation of this declaration is determined by the implementation. Such a default determination occurs no later than the end of the immediately enclosing declarative part, package specification, or task specification. For a declaration given in a declarative part, this default determination occurs before any enclosed \vbody\v333.. In the case of a type, certain occurrences of its name imply that the representation of the type must already have been determined. Consequently these occurrences force the default determination of any aspect of the representation not already determined by a prior type representation clause. This default determination is also forced by similar occurrences of the name of a subtype of the type, or of the name of any type or subtype that has \vsubcomponents\v305. of the type. A forcing occurence is any occurrence other than in a type or subtype declaration, a subprogram specification, an entry declaration, a \vdeferred\v704. \vconstant declaration\v704., a \vpragma\v1310., or a representation clause for the type itself. In any case, an occurrence within an \vexpression\v410. is always forcing. A representation clause for a given entity must not appear after an occurrence of the name of the entity if this occurrence forces a default determination of representation for the entity. Similar restrictions exist for address clauses. For an object, any occurrence of its name (after the object declaration) is a forcing occurrence. For a subprogram, package, task unit, or entry, any occurrence of a \vrepresentation attribute\v1310. of such an entity is a forcing occurrence. The effect of the elaboration of a representation clause is to define the corresponding aspects of the representation. The interpretation of some of the expressions that appear in representation clauses is implementation_dependent, for example, expressions specifying addresses. An implementation may limit its acceptance of representation clauses to those that can be handled simply by the underlying hardware. If a representation clause is accepted by an implementation, the compiler must guarantee that the net effect of the program is not changed by the presence of the clause, except for address clauses and for parts of the program that interrogate representation attributes. If a program contains a representation clause that is not accepted, the program is \villegal\v108.. For each implementation, the allowed representation clauses, and the conventions used for implementation-dependent expressions, must be documented in Appendix F of the reference manual. Whereas a representation clause is used to impose certain characteristics of the mapping of an entity onto the underlying machine, pragmas can be used to provide an implementation, with criteria for its selection of such a mapping. The pragma PACK specifies that storage minimization should be the main criterion when selecting the representation of a record or array type. Its form is as follows: pragma PACK (type_simple_name); Packing means that gaps between the storage areas allocated to consecutive \vcomponents\v305. should be minimized. It need not, however, affect the mapping of each component onto storage. This mapping can itself be influenced by a pragma (or controlled by a representation clause) for the component or component type. The position of a PACK pragma, and the restrictions on the named type, are governed by the same rules as for a representation clause; in particular, the pragma must appear before any use of a representation attribute of the packed entity. The pragma PACK is the only language-defied representation pragma. Additional representation pragmas may be provided by an implementation; these must be documented in Appendix F. (in contrast to representation clauses, a pragma that is not accepted by the implementation is ignored). Note: No representation clause is allowed for a \vgeneric formal type\v1203.. :1302 13.2 \uLength Clauses\n A length clause specifies an amount of storage associated with a type. length_clause ::= for \vattribute\v405. use simple_expression; The \vexpression\v410. \vmust\v108. be of some \vnumeric type\v310. and is evaluated during the \velaboration\v333. of the length clause (unless it is a \vstatic expression\v422.). The prefix of the attribute must denote either a type or a \vfirst named subtype\v321.. The prefix is called T in what follows. The only allowed attribute designators in a length clause are SIZE, STORAGE_SIZE, and SMALL. The effect of the length clause depends on the attribute designator: (a) Size specification: T'SIZE The expression must be a static expression of some \vinteger type\v314.. The value of the expression specifies an upper bound for the number of bits to be allocated to \vobjects\v302. of the type or first named subtype T. The size specification must \vallow\v108. for enough storage space to accommodate every allowable value of these objects. A size specification for a \vcomposite type\v305. may affect the size of the gaps between the storage areas allocated to consecutive components. On the other hand, it need not affect the size of the storage area allocated to each component. The size specification is only allowed if the \vconstraints\v305. on T and on its \vsubcomponents\v305. (if any) are static. In the case of an unconstrained \varray type\v321., the \vindex subtypes\v321. must also be static. (b) Specification of \vcollection\v330. size: T'STORAGE_SIZE The prefix T must denote an \vaccess type\v330.. The expression must be of some integer type (but need not be static); its value specifies the number of \vstorage units\v1308. to be reserved for the collection, that is, the storage space needed to contain all objects \vdesignated\v330. by values of the access type and by values of other types derived form the access type, directly or indirectly. This form of length clause is not allowed for a type derived from an access type. (c) Specification of storage for a \vtask activation\v903.: T'STORAGE _SIZE The prefix T must denote a \vtask type\v902.. The expression must be of some integer type (but need not be static); its value specifies the number of storage units to be reserved for an activation (not the code) of a task of the type. (d) Specification of small for a \vfixed point type\v319.: T'SMALL The prefix T must denote the first named subtype of a fixed point type. The expression must be a static expression of some \vreal type\v316.; its value must be greater than the delta of the first named subtype. The effect of the length clause is to use this value of small for the representation of values of the fixed point base type. (The length clause thereby also affects the amount of storage for objects that have this type). \uNotes:\n A size specification is allowed for an access, task, or fixed point type, whether or not another form of length clause is also given for the type. What is considered to be part of the storage reserved for a collection or for an activation of a \vtask\v900. is implementation-dependent. The control afforded by length clauses is therefore relative to the implementation conventions. For example, the language does not define whether the storage reserved for an activation of a task includes any storage needed for the collection associated with an access type declared within the task body. Neither does it define the method of allocation for objects denoted by values of an access type. For example, the space allocated could be on a stack; alternatively, a general dynamic aliocation scheme or fixed storage could be used. The objects allocated in a collection need not have the same size if the designated type is an unconstrained array type or an unconstrained type with discriminants. Note also that the \vallocator\v421. itself may require some space for internal tables and links. Hence a length clause for the collection of an access type does not always give precise control over the maximum number of allocated objects. \uExamples:\n --assumed declarations: \utype\n MEDIUM \uis range\n 0 .. 65000; \utype\n SHORT \uis delta\n 0.01 \urange\n -100.0 .. 100.0; \utype\n DEGREE \uis delta\n 0.1 \urange\n -360.0 .. 360.0; BYTE : \uconstant\n := 8; PAGE : \uconstant\n := 2000; --length clauses: \ufor\n COLOR'SIZE \uuse\n 1*BYTE; -- see 3.5.1 \ufor\n MEDIUM'SIZE \uuse\n 2*BYTE; \ufor\n SHORT'SIZE \uuse\n 15; \ufor\n CAR_NAME'STORAGE_SIZE \uuse\n -- approximately 2000 cars 2000*((CAR'SIZE/SYSTEM.STORAGE_UNIT) +1); \ufor\n KEYBOARD_DRIVERS'STORAGE_SIZE \uuse\n 1*PAGE; \ufor\n DEGREE'SMALL \uuse\n 360.0/2**(SYSTEM.STORAGE_UNIT -1); Notes on the \uExamples:\n In the length clause for SHORT, fifteen bits is the minimum necessary, since the type definition requires SHORT'SMALL=2**(-7) and SHORT'MANTISSA = 14. The length clause for DEGREE forces the model numbers to exactly span the range of the type. :1303 13.3 \uEnumeration Representation Clauses\n An enumeration \vrepresentation clause\v1301. specifies the internal codes for the \vliterals\v406. of the \venumeration type\v311. that is named in the clause. enumeration_representation_clause ::= for type_simple_name use \vaggregate\v407.; The aggregate used to specify this mapping is written as a one-dimensional aggregate, for which the \vindex subtype\v321. is the enumeration \vtype\v305. and the component \vtype is universal_integer\v314.. All literals of the enumeration type must be provided with distinct integer codes, and all \vchoices\v328.. and \vcomponent\v305. values given in the aggregate must be static. The integer codes specified for the enumeration type must satisfy the predefined \vordering relation\v311. of the type. Example: \utype\n MIX_CODE \uis\n (ADD, SUB, MUL, LDA, STA, STZ); \ufor\n MIX_CODE \uuse\n (ADD => 1, SUB =.2, MUL => 3, LDA => 8, STA => 24, STZ =>33); \uNotes:\n The attributes SUCC, PRED, and POS are defined even for enumeration types with a noncontiguous representation; their definition corresponds to the (logical) \vtype declaration\v306. and is not affected by the enumeration representation clause. In the example, because of the need to avoid the omitted values, these \vfunctions\v609. are likely to be less efficiently implemented than they could be in the absence of a representation clause. Similar considerations apply when such types are used for indexing. :1304 13.4 \uRecord Representation Clauses\n A record representation clause specifies the storage representation of records, that is, the order, position, and size of \vrecord components\v325. (including \vdiscriminants\v326., if any). record_representation_clause ::= \ufor\n type_simple_name \uuse\n \urecord\n [alignment_clause] {component clause} \uend record\n; alignment_clause ::= \uat mod\n static_simple_expression; component_clause ::= component_name at static_simple_expression \vrange\v310. static_range; The \vsimple expression\v410. given after the reserved words at mod in an alignment clause, or after the reserved word at in a component clause, \vmust\v108. be a \vstatic expression\v422. of some \vinteger type\v314.. If the bounds of the range of a component clause are defined by simple expressions, then each bound of the range must be defined by a static expression of some integer type, but the two bounds need not have the same integer type. An alignment clause forces each record of the given type to be allocated at a starting address that is a multiple of the value of the given expression (that is, the address modulo the expression must be zero). An implementation may place restrictions on the allowable alignments. A component clause specifies the storage place of a component, relative to the start of the record. The integer defined by the static expression of a component clause is a relative address expressed in \vstorage units\v1308.. The range defines the bit positions of the storage place, relative to the storage unit. The first storage unit of a record is numbered zero.The first bit of a storage unit is numbered zero. The ordering of bits in a storage unit is machine_dependent and may extend to adjacent storage units (For a specific machine, the size in bits of a storage unit is given by the configuration-dependent \vnamed number\v302. SYSTEM.STORAGE_UNIT.) Whether a component is allowed to overlap a storage boundary, and if so, how, is implementation-defined. At most one component clause is allowed for each component of the record type, including for each discriminant (component clauses may be given for some, all, or none of the components). If no component clause is given for a component, then the choice of the storage place for the component is left to the compiler. If component clauses are given for all components, the record representation clause completely specifies the representation of the \vrecord type\v325. and must be obeyed exactly by the compiler. Storage places within a record \vvariant\v328. must not overlap, but overlap of the storage for distinct variants is allowed. Each component clause must \vallow\v108. for enough storage space to accommodate every allowable value of the component. A component clause is only allowed for a component if any \vconstraint\v305. on this component or on any of its \vsubcomponents\v305. is static. An implementation may generate names that denote implementation-dependent components (for example, one containing the offset of another component). Such implementation-dependent names can be used in record representation clauses (these names need not be \vsimple names\v401.; for example, they could be implementation-dependent \vattributes\405.). Example: WORD : \vconstant\v303. := 4; -- storage unit is byte, 4 bytes per word \utype\n STATE \uis\n (A,M,W,P); \utype\n MODE \uis\n (FIX, DEC, EXP, SIGNIF); \utype\n BYTE_MASK \uis array\n (0.. 7) \uof\n BOOLEAN; \utype\n STATE_MASK \uis array\n (STATE) \uof\n BOOLEAN; \utype\n MODE_MASK \uis array\n (MODE) \uof\n BOOLEAN; \utype\n PROGRAM_STATUS_WORD \uis\n \urecord\n SYSTEM_MASK : BYTE_MASK; PROTECTION_KEY : INTEGER range 0 .. 3; MACHINE_STATE : STATE_MASK; INTERRUPT_CAUSE : INTERRUPTION_CODE; ILC : INTEGER range 0 .. 3; CC : INTEGER range 0 .. 3; PROGRAM_MASK : MODE_MASK; INST_ADDRESS : ADDRESS; \uend record\n; \ufor\n PROGRAM_STATUS_WORD \uuse\n \urecord at mod\n 8; SYSTEM_MASK \uat\n 0*WORD \urange\n 0 .. 7; PROTECTION_KEY \uat\n 0*WORD \urange\n 10 .. 11; -- bits 8,9 unused MACHINE_STATE \uat\n 0*WORD \urange\n 12 .. 15; INTERRUPT_CAUSE \uat\n 0*WORD \urange\n 16 .. 31; ILC \uat\n 1*WORD \urange\n 0 .. 1; -- second word CC \uat\n 1*WORD \urange\n 2 .. 3; PROGRAM_MASK \uat\n 1*WORD \urange\n 4 .. 7; INST_ADDRESS \uat\n 1*WORD \urange\n 8 .. 31; \uend record\n; \ufor\n PROGRAM_STATUS_WORD'SIZE \uuse\n 8*SYSTEM.STORAGE_UNIT; Note on the example: The record representation clause defines the record layout. The length clause guarantees that exactly eight storage units are used. :1305 13.5 \uAddress Clauses\n An address clause specifies a required address in storage for an \ventity\v301.. address_clause ::= for simple_name use at simple_expression; The \vexpression\v410. given after the \vreserved word\v211. at must be of the \vtype\v305. ADDRESS defined in the \vpackage\v700. SYSTEM (see 13.7); this package must be named by a \vwith clause\v1002. that applies to the \vcompilation unit\v1001. in which the address clause occurs. The conventions that define the interpretation of a value of the type ADDRESS as an address, as an interrupt level, or whatever it may be, are implementation-dependent. The allowed nature of the simple \vname\v401. and the meaning of the corresponding address are as follows: (a) Name of an \vobject\v302.: the address is that required for the object (\vvariable\v303. or \vconstant\v303.). (b) Name of a \vsubprogram\v600., package, or \vtask unit\v900.: the address is that required for the machine code associated with the body of the program unit. (c) Name of a single \ventry\v905.: the address specifies a hardware interrupt to which the single entry is to be linked. If the simple name is that of a single task, the address clause is understood to refer to the task unit and not to the \vtask object\v901.. In all cases, the address clause is only legal if exactly one declaration with this identifier occurs earlier, immediately within the same declarative part, package specification, or task specification. A name declared by a renaming declaration is not allowed as the \vsimple name\v401.. Address clauses should not be used to achieve overlays of objects or overlays of \vprogram units\v600.. Nor should a given interrupt be linked to more than one entry. Any program using address clauses to achieve such effects is \verroneous\v108.. Example: \ufor\n CONTROL \uuse at\n 16#0020#; -- assuming that SYSTEM.ADDRESS is an integer type \uNotes:\n The above rules imply that if two subprograms overload each other and are visible at a given point, an address clause for any of them is not legal at this point. Similarly if a task specification declares entries that overload each other, they cannot be interrupt entries. The syntax does not allow an address clause for a \vlibrary unit\v1001.. An implementation may provide \vpragmas\v210. for the specification of program overlays. More details: 13.5.1 \vInterrupts\v1306. :1306 13.5.1 \uInterrupts\n An address clause given for an \ventry\v905. associates the entry with some device that may cause an interrupt; such an entry is referred to in this section as an interrupt entry. If control information is supplied upon an interrupt, it is passed to an associated interrupt entry as one or more parameters of \vmode\v601. in; only parameters of this mode are \vallowed\v108.. An interrupt acts as an entry call issued by a hardware \vtask\v900. whose priority is higher than the priority of the main program, and also higher than the priority of any user-defined task (that is, any task whose type is declared by a task unit in the program). The entry call may be an ordinary entry call, a \vtimed entry call\v910., or a \vconditional entry call\v909., depending on the kind of interrupt and on the implementation. If a \vselect statement\v907. contains both a \vterminate alternative\v908. and an \vaccept\v908. \valternative\v908. for an interrupt entry, then an implementation may impose further requirements for the selection of the terminate alternative in addition to those given in section 9.4. Example: \utask\n INTERRUPT_HANDLER \uis\n \uentry\n DONE; \ufor\n DONE \uuse at\n 16#40#; assuming that SYSTEM.ADDRESS is an integer type \uend\n INTERRUPT_HANDLER; \uNotes:\n Interrupt entry calls need only have the semantics described above; they may be implemented by having the hardware directly execute the appropriate accept statements. Queued interrupts correspond to ordinary entry calls. Interrupts that are lost if not immediately processed correspond to conditional entry calls. It is a consequence of the priority rules that an \vaccept statement\v905. executed in response to an interrupt takes precedence over ordinary, user-defined tasks, and can be executed without first invoking a scheduling action. One of the possible effects of an address clause for an interrupt entry is to specify the priority of the interrupt (directly or indirectly). Direct calls to an interrupt entry are allowed. :1307 13.6 \uChange of Representation\n At most one \vrepresentation clause\v1301. is allowed for a given \vtype\v305. and a given aspect of its representation. Hence, if an alternative representation is needed, it is necessary to declare a second type, \vderived\v309. from the first, and to specify a different representation for the second type. Example: -- PACKED_DESCRIPTOR and DESCRIPTOR are two different types -- with identical characteristics, apart from their representation \utype\n DESCRIPTOR \uis\n \urecord\n -- components of a descriptor \uend record\n; \utype\n PACKED_DESCRIPTOR \uis new\n DESCRIPTOR; \ufor\n PACKED_DESCRIPTOR \uuse\n \urecord\n -- component clauses for some or for all components \uend record\n; Change of representation can now be accomplished by \vassignment\v502. with explicit \vtype conversions\v419.: D : DESCRIPTOR; P : PACKED_DESCRIPTOR; P := PACKED_DESCRIPTOR (D); -- pack D D := DESCRIPTOR(P); -- unpack P :1308 13.7 \uThe Package System\n For each implementation there is a predefined library \vpackage\v700. called SYSTEM which includes the definitions of certain configuration-dependent characteristics. The specification of the package SYSTEM is implementation-dependent and \vmust\v108. be given in Appendix F. The visible part of this package must contain at least the following declarations. package SYSTEM is \vtype\v305. ADDRESS \uis\n implementation_defined; \utype\n NAME \uis\n implementation_defined_enumeration_type; SYSTEM_NAME : \uconstant\n NAME := implementation_defined; STORAGE_UNIT : \uconstant\n := implementation_defined; MEMORY_SIZE : \uconstant\n := implementation_defined; --System-Dependent \vNamed Numbers\v302.: MIN_INT : \uconstant\n := implementation_defined; MAX_INT : \uconstant\n := implementation_defined; MAX_DIGITS : \uconstant\n := implementation_defined; MAX_MANTISSA : \uconstant\n := implementation_defined; FINE_DELTA : \uconstant\n := implementation_defined; TICK : \uconstant\n := implementation_defined; --Other System_Dependent Declarations \usubtype\n PRIORITY \uis\n INTEGER \urange\n implementation_defined; ... \uend\n SYSTEM; The type ADDRESS is the type of the addresses provided in \vaddress clauses\v1305.; it is also the type of the result delivered by the \vattribute\v405. ADDRESS. Values of the enumeration type NAME are the names of alternative machine configurations handled by the implementation; one of these is the constant SYSTEM_NAME. The named number STORAGE_UNIT is the number of bits per storage unit; the named number MEMORY_SIZE is the number of available storage units in the configuration; these named numbers are of the type universal_integer. An alternative form of the package SYSTEM, with given values for any of SYSTEM_NAME, STORAGE_UNIT, and MEMORY_SIZE, can be obtained by means of the corresponding \vpragmas\v210.. These pragmas are only allowed at the start of a compilation, before the first \vcompilation unit\v1001. (if any) of the compilation. \upragma\n SYSTEM_NAME (enumeration_literal); The effect of the above pragma is to use the enumeration literal with the specified identifier for the definition of the constant SYSTEM_NAME. This pragma is only allowed if the specified identifier corresponds to one of the literals of the type NAME. \upragma\n STORAGE_UNIT (\vnumeric_literal\v204.); The effect of the above pragma is to use the value of the specified numeric literal for the definition of the named number STORAGE_UNIT. \upragma\n MEMORY_SIZE (numeric_literal); The effect of the above pragma is to use the value of the specified numeric literal for the definition of the named number MEMORY_SIZE. The compilation of any of these pragmas causes an implicit recompilation of the package SYSTEM. Consequently any compilation unit that names SYSTEM in its context clause becomes obsolete after this implicit recompilation. An implementation may impose further limitations on the use of these pragmas. For example, an implementation may allow them only at the start of the first compilation, when creating a new \vprogram library\v1001.. Note: It is a consequence of the \vvisibility\v803. rules that a declaration given in the package SYSTEM is not visible in a compilation unit unless this package is mentioned by a \vwith clause\v1002. that applies (directly or indirectly) to the compilation unit. More details: 13.7.1 \vSystem Dependent Named Numbers\v1309. 13.7.2 \vRepresentation Attributes\v1310. 13.7.3 \vRepresentation Attributes of Real Types\v1311. :1309 13.7.1 \uSystem-dependent Named Numbers\n Within the \vpackage SYSTEM\v1308., the following \vnamed numbers\v302. are declared. The numbers FINE_DELTA and TICK are of the \vtype\v305. \vuniversal_real\v316.; the others are of the type \vuniversal_integer\v314.. MIN_INT The smallest (most negative) value of all predefined integer types. MAX_INT The largest (most positive) value of all predefined \vinteger\v314. \vtypes\v314.. MAX_DIGITS The largest value \vallowed\v108. for the number of significant decimal digits in a \vfloating point constraint\v317.. MAX_MANTISSA The largest possible number of binary digits in the mantissa of \vmodel numbers\v316. of a fixed point subtype. FINE_DELTA The smallest delta allowed in a \vfixed point constraint\v319. that has the \vrange constraint\v310. -1.0 .. 1.0. TICK The basic clock period, in seconds. :1310 13.7.2 \uRepresentation Attributes\n The values of certain implementation-dependent characteristics can be obtatined by interrogating appropriate representation attributes. These attributes are described below. For any \vobject\v302., \vprogram unit\v600., \vlabel\v501., or \ventry\v905. X: X'ADDRESS Yields the address of the first of the \vstorage units\v1308. allocated to X. For a \vsubprogram\v600., \vpackage\v700., \vtask unit\v900. or label, this value refers to the machine code associated with the corresponding body or \vstatement\v500.. For an entry for which an \vaddress clause\v1305. has been given, the value refers to the corresponding hardware interrupt. The value of this attribute is of the \vtype\v305. ADDRESS defined in the package SYSTEM. For any type or \vsubtype\v305. X or for any object X: X'SIZE Applied to an object, yields the number of bits allocated to hold the object. Applied to a type or subtype, yields the minimum number of bits that is needed by the implementation to hold any possible object of this type or subtype. The value of this attribute is of the type \vuniversal_integer\v314.. For the above two representation attributes, if the prefix is the name of a function, the attribute is understood to be an attribute of the function (not of the result of calling the function). Similarly, if the type of the prefix is an \vaccess type\v330., the attribute is understood to be an attribute of the prefix (not of the designated object: attributes of the latter can be written with a prefix ending with the reserved word \uall\n). For any \vcomponent\v305. C of a \vrecord object\v325. R: R.C'POSITION Yields the offset, from the start of the first storage unit occupied by the record, of the first of the storage units occupied by C. This offset is measured in storage units. The value of this attribute is of the type universal_integer. R.C'FIRST_BIT Yields the offset, from the start of the first of the storage units occupied by C, of the last bit occupied by C. This offset is measured in bits. The value of this attribute is of the type universal_integer. R.C'LAST_BIT Yields the offset, from the start of the first of the storage units occupied by C, of the last bit occupied by C. This offset is measured in bits. The value of this attribute is of the type universal_integer. For any \vaccess type or subtype\v330. T: T'STORAGE_SIZE Yields the total number of storage units reserved for the \vcollection\v330. associated with the \vbase type\v305. of T. The value of this attribute is of the type universal_integer. For any \vtask type\v902. or \vtask object\v902. T: T'STORAGE_SIZE Yields the number of storage units reserved for each \vactivation\v903. of a task of the type T or for the activation of the task object T. The value of this attribute is of the type universal_integer. \uNotes:\n For a task object X, the attribute X'SIZE gives the number of bits used to hold the object X, whereas X'STORAGE_SIZE gives the number of storage units allocated for the activation of the task designated by X. For a \vformal\v601. \vparameter\v601. X, if \vparameter passing\v602. is achieved by copy, then the attribute X'ADDRESS yields the address of the local copy; if parameter passing is by reference, then the address is that of the \vactual parameter\v602.. :1311 13.7.3 \uRepresentation Attributes of Real Types\n For every \vreal type\v316. or \vsubtype\v305. T, the following machine-dependent \vattributes\v405. are defined, which are not related to the \vmodel numbers\v316.. Programs using these attributes may thereby exploit properties that go beyond the minimal properties associated with the \vnumeric type\v310. (see section 4.5.7 for the rules defining the accuracy of operations with real operands). Precautions must therefore be taken when using these machine- dependent attributes if portability is to be ensured. For both \vfloating point\v317. and \vfixed point types\v319.: T'MACHINE_ROUNDS Yields the value TRUE if every predefined arithmetic operation on values of the \vbase type\v305. of T either returns an exact result or performs rounding; yields the value FALSE otherwise. The value of this attribute is of the predefined type \vBOOLEAN\v313.. T'MACHINE_OVERFLOWS Yields the value TRUE if every \vpredefined operation\v308. on values of the base type of T either provides a correct result, or raises the exception \vNUMERIC_ERROR\v1101. in overflow situations (see 4.5.7); yields the value FALSE otherwise. The value of this attribute is of the predefined type BOOLEAN. For floating point types, the following attributes provide characteristics of the underlying machine representation, in terms of the canonical form defined in section 3.5.7: T'MACHINE_RADIX Yields the value of the \vradix\v317. used by the machine representation of the base type of T (the digits are extended digits in the range 0 to T'MACHINE_RADIX -1). The value of this attribute is of the type universal_integer. T'MACHINE_EMAX Yields the largest value of exponent for the machine representation of the base type of T. The value of this attribute is of the type universal_integer. T'MACHINE_EMIN Yields the smallest (most negative) value of exponent for the machine representation of the base type of T. The value of this attribute is of the type universal_integer. Note: For many machines the largest machine representable number of type F is almost (F'MACHINE_RADIX)**(F'MACHINE_EMAX), and the smallest positive representable number is F'MACHINE_RADIX ** (F'MACHINE_EMIN -1) :1312 13.8 \uMachine Code Insertions\n A machine code insertion can be achieved by a call to a \vprocedure\v600. whose \vsequence of statements\v501. contains code \vstatements\v500.. code_statement ::= type_mark'record_aggregate; A code statement is only \vallowed\v108. in the sequence of statements of a \vprocedure body\v603.. If a procedure body contains code statements, then within this procedure body the only allowed form of statement is a code statement (\vlabeled\v501. or not), the only allowed \vdeclarative items\v333. are \vuse clauses\v505., and no \vexception handler\v1102. is allowed (\vcomments\v209. and \vpragmas\v210. are allowed as usual). Each machine instruction appears as a record aggregate of a \vrecord type\v325. that defines the corresponding instruction. The base type of the type mark of a code statement must be declared within the predefined library \vpackage\v700. called MACHINE_CODE; this package must be named by a \vwith clause\v1002. that applies to the \vcompilation unit\v1001. in which the code statement occurs. An implementation is not required to provide such a package. An implementation is allowed to impose further restrictions on the \vrecord\v408. \vaggregates\v408. allowed in code statements. For example, it may require that expressions contained in such aggregates be \vstatic expressions\v422.. An implementation may provide machine-dependent pragmas specifying register conventions and calling conventions. Such pragmas must be documented in Appendix F Example: M : MASK \uprocedure\n SET_MASK; \upragma\n INLINE(SET_MASK); \uprocedure\n SET_MASK \uis\n \uuse\n MACHINE_CODE; \ubegin\n SI_FORMAT'(CODE => SSM, B => M'BASE_REG, D => M'DISP); -- M'BASE_REG and M'DISP are implementation-specific predefined attributes \uend\n; :1313 13.9 \uInterface to Other Languages\n A subprogram written in another language can be called from an Ada program provided that all communication is achieved via parameters and function results. A \vpragma\v210. of the form \upragma\n INTERFACE (language_name, subprogram_name); \vmust\v108. be given for each such \vsubprogram\v600.; a subprogram \vname\v401. is \vallowed\v108. to stand for several \voverloaded subprograms\v610.. This pragma is allowed at the place of a \vdeclarative item\v333., and must apply in this case to a subprogram declared by an earlier declarative item of the same \vdeclarative part\v333. or \vpackage specification\v701.. The pragma is also allowed for a \vlibrary unit\v1001.; in this case the pragma must appear after the subprogram \vdeclaration\v301., and before any subsequent \vcompilation unit\v1001.. The pragma specifies the other language (and therby the calling conventions ) and informs the compiler that an object module will be supplied for the corresponding subprogram. A body is not allowed for such a subprogram (not even in the form of a body stub) since the instructions of the subprogram are written in another language. This capability need not be provided by all implementations. An implementation may place restrictions on the allowable forms and places of parameters and calls. Example: \upackage\n FORT_LIB \uis\n \ufunction\n SQRT (X : FLOAT) \ureturn\n FLOAT; \ufunction\n EXP (X : FLOAT) \ureturn\n FLOAT; \uprivate\n \upragma\n INTERFACE(FORTRAN, SQRT); \upragma\n INTERFACE(FORTRAN, EXP); \uend\n FORT_LIB; \uNotes:\n The conventions used by other language processors that call Ada programs are not part of the Ada language definition. Such conventions must be defined by these other language processors. The pragma INTERFACE is not defined for generic subprograms. :1314 13.10 \uUnchecked Programming\n The predefined generic library subprograms UNCHECKED_DEALLOCATION and UNCHECKED_CONVERSION are used for unchecked storage deallocation and for unchecked \vtype\v305. conversions. generic \utype\n OBJECT \uis limited private\n; \utype\n NAME \uis access\n OBJECT; \uprocedure\n UNCHECKED_DEALLOCATION(X: \uin out\n NAME); generic \utype\n SOURCE \uis limited private\n; \utype\n TARGET \uis limited private\n; \ufunction\n UNCHECKED_CONVERSION(S : SOURCE) \ureturn\n TARGET; More details: 13.10.1 \vUnchecked Storage Deallocation\v1315. 13.10.2 \vUnchecked Type Conversions\v1316. :1315 13.10.1 \uUnchecked Storage Deallocation\n Unchecked storage deallocation of an object \vdesignated\v330. by a value of an \vaccess type\v330. is achieved by a call of a \vprocedure\v600. that is obtained by instantiation of the \vgeneric procedure\v1201. UNCHECKED_DEALLOCATION. For example: \uprocedure\n FREE \uis new\n UNCHECKED_DEALLOCATION(object_type_name, access_type_name); Such a FREE procedure has the following effect: (a) after executing FREE(X), the value of X is null; (b) FREE(X), when X is already equal to null, has no effect; (c) FREE(X), when X is not equal to null, is an indication that the \vobject\v302. designated by X is no longer required, and that the storage it occupies is to be reclaimed. If X and Y designate the same object, then accessing this object through Y is \verroneous\v108. if this access is performed (or attempted) after the call FREE(X); the efeect of each such access is not defined by the language. \uNotes:\n It is a consequence of the \vvisibility\v803. rules that the generic procedure UNCHECKED_DEALLOCATION is not visible in a \vcompilation unit\v1001. unless this generic procedure is mentioned by a \vwith clause\v1002. that applies to the compilation unit. If X designates a \vtask object\902., the call FREE(X); has no effect on the \vtask\v900. designated by the value of this task object. The same holds for any \vsubcomponent\v305. of the object designated by X, if this subcomponent is a task object. :1316 13.10.2 \uUnchecked Type Conversions\n An unchecked type conversion can be achieved by a call of a function that is obtained by \vinstantiation\v1206. of the \vgeneric function\v1201. UNCHECKED_CONVERSION. The effect of an unchecked conversion is to return the (uninterpreted) parameter value as a value of the target \vtype\v305., that is, the bit pattern defining the source value is returned unchanged as the bit pattern defining a value of the target type. An implementation may place restrictions on unchecked conversions, for example, restrictions dependeing on the respective sizes of objects of the source and target type. Such restrictions must be documented in appendix F. Whenever unchecked conversions are used, it is the programmer's responsibility to ensure that these conversions maintain the properties that are guaranteed by the language for objects of the target type. Programs that violate these properties by means of unchecked conversions are \verroneous\v108.. Note: It is a consequence of the visibility rules that the generic function UNCHECKED_CONVERSION is not visible in a \vcompilation unit\v1001. unless this generic function is mentioned by a \vwith clause\v1001. that applies to the compilation unit. :1400 14. \uInput-Output\n Input-output is provided in the language by means of predefined packages. The generic packages \vSEQUENTIAL_IO\v1402. and \vDIRECT_IO\v1402. define input-output operations applicable to files containing elements of a given type. Additional operations for text input-output are supplied in the \vpackage\v1408. \vTEXT_IO\v1408.. The \vpackage IO_EXCEPTIONS\v1420. defines the exceptions needed by the above three packages. Finally, a \vpackage LOW_LEVEL_IO\v1421. is provided for direct control of peripheral devices. More details: 14.1 \vExternal Files and File Objects\v1401. 14.2 \vSequential and Direct Files\v1402. 14.3 \vText Input-Output\v1408. 14.4 \vExceptions in Input-Output\v1419. 14.5 \vSpecification of the Package IO_EXCEPTIONS\v1420. 14.6 \vLow Level Input-Output\v1421. 14.7 \vExample of Input-Output\v1422. :1401 14.1 \uExternal Files and File Objects\n Values input from the external environment of the program, or output to the environment, are considered to occupy external files. An external file can be anything external to the program that can produce a value to be read or receive a value to be written. An external file is identified by a \vstring\v324. (the name). A second string (the form) gives further system-dependent characteristics that may be associated with the file, such as the physical organization or access rights. The conventions governing the interpretation of such strings must be documented in Appendix F. Input and output operations are expressed as operations on objects of some file type, rather than directly in terms of the external files. In the remainder of this chapter, the term file is always used to refer to a file object; the term external file is used otherwise. The values transferred for a given file must all be of one type. Input-output for \vsequential files\v1402. of values of a single element type is defined by means of the generic package SEQUENTIAL_IO. The skeleton of this package is given below. \uwith\n IO_EXCEPTIONS; \ugeneric\n \utype\n ELEMENT_TYPE \uis private\n; \vpackage SEQUENTIAL_IO\v1402. \uis\n \utype\n FILE_TYPE \uis limited private\n; \utype\n \vFILE_MODE\v1405. \uis\n (IN_FILE, OUT_FILE); ... \vprocedure OPEN\v1403. (FILE : \uin out\n FILE_TYPE; ...); ... \vprocedure READ\v1406. (FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE); \vprocedure WRITE\v1406.(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE); ... \uend\n SEQUENTIAL_IO; In order to define \vsequential input-output\v1404. for a given element type, an instantiation of this generic unit, with the given type as actual parameter, must be declared. The resulting package contains the declaration of a file type (called FILE_TYPE) for files of such elements, as well as the operations applicable to these files, such as the OPEN, READ, and WRITE procedures. Input-output for \vdirect access\v1402. files is likewise defined by a generic package called \vDIRECT_IO\v1402.. Input-output in human-readable form is defined by the (nongeneric) \vpackage TEXT_IO\v1408.. Before \vinput\v1404. or \voutput\v1404. operations can be performed on a file, the file must first be associated with an external file. While such an association is in effect, the file is said to be open, and otherwise the file is said to be closed. The language does not define what happens to external files after the completion of the main program (in particular, if corresponding files have not been closed). The effect of input-output for access types is implementation-dependent. An open file has a current mode, which is a value of one of the \venumeration\v311. \vtypes\v311. \utype\n FILE_MODE \uis\n (IN_FILE, INOUT_FILE, OUT_FILE); -- for DIRECT_IO \utype\n FILE_MODE \uis\n (IN_FILE, OUT_FILE); -- for SEQUENTIAL_IO and TEXT_IO These values correspond respectively to the cases where only reading, both reading and writing, or only writing are to be performed. The mode of a file can be changed. Several file management operations are common to the three input-output packages. These operations are described in section 14.2.1 for sequential and \vdirect files\v1402.. Any additional effects concerning text input-output are described in section 14.3.1. The \vexceptions\v1100. that can be raised by a call of an input-output subprogram are all defined in the \vpackage IO_EXCEPTIONS\v1420.; the situations in which they can be raised are described, either following the description of the subprogram (and in section 14.4), or in Appendix F in the case of error situations that are implementation-dependent. \uNotes:\n Each instantiation of the generic packages SEQUENTIAL_IO and DIRECT_IO declares a different type FILE_TYPE; in the case of TEXT_IO, the type FILE_TYPE is unique. A bidirectional device can often be modeled as two sequential files associated with the device, one of mode IN_FILE, and one of mode OUT_FILE. An implementation may restrict the number of files that may be associated with a given external file. The effect of sharing an external file in this way by several file objects is implementation-dependent. :1402 14.2 \uSequential and Direct Files\n Two kinds of access to external files are defined: sequential access and direct access. The corresponding file types and the associated operations are provided by the generic packages SEQUENTIAL_IO and DIRECT_IO. A file object to be used for sequential access is called a sequential file, and one to be used for direct access is called a direct file. For sequential access, the file is viewed as a sequence of values that are transferred in the order of their appearance (as produced by the program or by the environment). When the file is opened, transfer starts from the beginning of the file. For direct access, the file is viewed as a set of elements occupying consecutive positions in linear order; a value can be transferred to or from an element of the file at any selected position. The position of an element is specified by its index, which is a number, greater than zero, of the implementation-defined integer type \vCOUNT\v1408.. The first element, if any, has index one; the index of the last element, if any, is called the current size; the current size is zero if there are no elements. The current size is a property of the external file. An open direct file has a current index, which is the index that will be used by the next read or write operation. When a direct file is opened, the current index is set to one. The current index of a direct file is a property of a file object, not of an external file. All three \vfile modes\v1401. are allowed for direct files. The only allowed modes for sequential files are the modes \vIN_FILE\v1401. and \vOUT_FILE\v1401.. More details: 14.2.1 \vFile Management\v1403. 14.2.2 \vSequential Input-Output\v1404. 14.2.3 \vSpecification of the Package Sequential_IO\v1405. 14.2.4 \vDirect Input-Output\v1406. 14.2.5 \vSpecification of the Package Direct_IO\v1407. :1403 14.2.1 \uFile Management\n The procedures and functions described in this section provide for the control of \vexternal files\v1401.; their declarations are repeated in each of the three packages for sequential, direct, and text input-output. For text input-output, the procedures CREATE, OPEN, and RESET have additional effects described in section 14.3.1. \uprocedure\n CREATE(FILE : \uin out\n \vFILE_TYPE\v1401.; \vMODE\v1401. : \uin\n \vFILE_MODE\v1401. := default_mode; \vNAME\v1401. : \uin\n STRING := ""; FORM : \uin\n STRING := ""); Establishes a new external file, with the given name and form, and associates this external file with the given \vfile\v1401.. The given file is left open. The \vcurrent mode\v1401. of the given file is set to the given access mode. The default access mode is the mode \vOUT_FILE\v1401. for sequential and text input-output; it is the mode \vINOUT_FILE\v1406. for direct input-output. For \vdirect access\v1402., the size of the created file is implementation-dependent. A null string for NAME specifies an external file that is not accessible after the completion of the main program (a temporary file). A null string for FORM specifies the use of the default options of the implementation for the external file. The \vexception STATUS_ERROR\v1419. is raised if the given file is already \vopen\v1401.. The \vexception NAME_ERROR\v1419. is raised if the string given as NAME does not allow the identification of an external file. The \vexception USE_ERROR\v1419. is raised if, for the specified mode, the environment does not support creation of an external file with the given name (in the absence of NAME_ERROR) and form. \uprocedure\n OPEN(FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE; NAME : \uin\n STRING; FORM : \uin\n STRING := ""); Associates the given file with an existing external file having the given name and form, and sets the current mode of the given file to the given mode. The given file is left open. The exception STATUS_ERROR is raised if the given file is already open. The exception NAME_ERROR is raised if the string given as NAME does not allow the identification of an external file; in particular, this exception is raised if no external file with the given name exists. The exception USE_ERROR is raised if, for the specified mode, the environment does not support opening for an external file with the given name (in the absence of NAME_ERROR) and form. \uprocedure\n CLOSE(FILE : \uin out\n FILE_TYPE); Severs the association between the given file and its associated external file. The given file is left closed. The exception STATUS_ERROR is raised if the given file is not open. \uprocedure\n DELETE(FILE : \uin out\n FILE_TYPE); Deletes the external file associated with the given file. The given \vfile is closed\v1401., and the external file ceases to exist. The exception STATUS_ERROR is raised if the given file is not open. The exception USE_ERROR is raised if (as fully defined in Appendix F) deletion of the external file is not supported by the environment. \uprocedure\n RESET(FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE); \uprocedure\n RESET(FILE : \uin out\n FILE_TYPE); Resets the given file so that reading from or writing to its elements can be restarted from the beginning of the file; in particular, for direct access this means that the current index is set to one. If a MODE parameter is supplied, the current mode of the given file is set to the given mode. The exception STATUS_ERROR is raised if the file is not open. The exception USE_ERROR is raised if the environment does not support resetting for the external file and, also, if the environment does not support resetting to the specified mode for the external file. \ufunction\n MODE(FILE : \uin\n FILE_TYPE) \ureturn\n FILE_MODE; Returns the current mode of the given file. The exception STATUS_ERROR is raised if the file is not open. \ufunction\n NAME(FILE : \uin\n FILE_TYPE) \ureturn\n STRING; Returns a string which uniquely identifies the external file currently associated with the given file (and may thus be used in an OPEN operation). If an environment allows alternative specifications of the name (for example, abbreviations), the string returned by the function should correspond to a full specification of the name. The exception STATUS_ERROR is raised if the given file is not open. \ufunction\n FORM(FILE : \uin\n FILE_TYPE) \ureturn\n STRING; Returns the \vform string\v1401. for the external file currently associated with the given file. If an environment allows alternative specifications of the form (for example, abbreviations using default options), the string returned by the function should correspond to a full specification (that is, it should indicate explicitly all options selected, including default options). The exception STATUS_ERROR is raised if the given file is not open. \ufunction\n IS_OPEN(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; Returns TRUE if the file is open (that is, if it is associated with an external file), otherwise returns FALSE. :1404 14.2.2 \uSequential Input-Output\n The operations available for sequential input and output are described in this section. The \vexception STATUS_ERROR\v1419. is raised if any of these operations is attempted for a \vfile\v1401. that is not open. \uprocedure\n READ(FILE : \uin\n \vFILE_TYPE\v1401.; ITEM : \uout\n \vELEMENT_TYPE\v1401.); Operates on a file of mode \vIN_FILE\v1401.. Reads an \velement\v1401. from the given file, and returns the value of this element in the ITEM parameter. The \vexception MODE_ERROR\v1419. is raised if the mode is not IN_FILE. The \vexception END_ERROR\v1419. is raised if no more elements can be read from the given file. The \vexception DATA_ERROR\v1419. is raised if the element read cannot be interpreted as a value of the type ELEMENT_TYPE; however, an implementation is allowed to omit this check if performing the check is too complex. \uprocedure\n WRITE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE); Operates on a file of mode \vOUT_FILE\v1401.. Writes the value of ITEM to the given file. The exception MODE_ERROR is raised if the \vmode\v1401. is not OUT_FILE. The \vexception USE_ERROR\v1419. is raised if the capacity of the \vexternal\v1401. \vfile\v1401. is exceeded. \ufunction\n END_OF_FILE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; Operates on a file of mode IN_FILE. Returns TRUE if no more elements can be read from the given file; otherwise returns FALSE. The exception MODE_ERROR is raised if the mode is not IN_FILE. :1405 14.2.3 \uSpecification of the Package Sequential_IO\n with \vIO_EXCEPTIONS\v1419.; generic \utype\n ELEMENT_TYPE \uis private\n; \vpackage SEQUENTIAL_IO\v1402. \uis\n \utype\n \vFILE_TYPE\v1401. \uis limited private\n; \utype\n \vFILE_MODE\v1401. \uis\n (\vIN_FILE\v1401., \vOUT_FILE\v1401.); -- File management \vprocedure CREATE\v1403.(FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE := OUT_FILE; NAME : \uin\n STRING := ""; FORM : \uin\n STRING := ""); \vprocedure OPEN\v1403. (FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE; NAME : \uin\n STRING; FORM : \uin\n STRING := ""); \vprocedure CLOSE\v1403. (FILE : \uin out\n FILE_TYPE); \vprocedure DELETE\v1403.(FILE : \uin out\n FILE_TYPE); \vprocedure RESET\v1403. (FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE); \uprocedure\n RESET (FILE : \uin out\n FILE_TYPE); \vfunction MODE\v1403. (FILE : \uin\n FILE_TYPE) \ureturn\n FILE_MODE; \vfunction NAME\v1403. (FILE : \uin\n FILE_TYPE) \ureturn\n STRING; \vfunction FORM\v1403. (FILE : \uin\n FILE_TYPE) \ureturn\n STRING; \vfunction IS_OPEN\v1403.(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; -- Input and output operations \vprocedure READ\v1404. (FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE); \vprocedure WRITE\v1404. (FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE); \vfunction END_OF_FILE\v1404.(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; -- Exceptions \vSTATUS_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.STATUS_ERROR; \vMODE_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.MODE_ERROR; \vNAME_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.NAME_ERROR; \vUSE_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.USE_ERROR; \vDEVICE_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.DEVICE_ERROR; \vEND_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.END_ERROR; \vDATA_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.DATA_ERROR; \uprivate\n -- implementation-dependent \uend\n SEQUENTIAL_IO; :1406 14.2.4 \uDirect Input-Output\n The operations available for direct input and output are described in this section. The \vexception STATUS_ERROR\v1419. is raised if any of these operations is attempted for a \vfile\v1401. that is not \vopen\v1401.. \uprocedure\n READ(FILE : \uin\n \vFILE_TYPE\v1401.; ITEM : \uout\n \vELEMENT_TYPE\v1401.; FROM : \uin \n \vPOSITIVE_COUNT\v1408.); \uprocedure\n READ(FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE); Operates on a file of mode \vIN_FILE\v1401. or \vINOUT_FILE\v1401.. In the case of the first form, sets the \vcurrent index\v1402. of the given file to the \vindex\v1402. value given by the parameter FROM. Then (for both forms) returns, in the parameter ITEM, the value of the \velement\v1401. whose position in the given file is specified by the current index of the file; finally, increases the current index by one. The \vexception MODE_ERROR\v1419. is raised if the \vmode\v1401. of the given file is OUT_FILE. The \vexception END_ERROR\v1419. is raised if the index to be used exceeds the size of the \vexternal file\v1401.. The \vexception\v1419. \vDATA_ERROR\v1419. is raised if the element read cannot be interpreted as a value of the type ELEMENT_TYPE; however, an implementation is allowed to omit this check if performing the check is too complex. \uprocedure\n WRITE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE; TO : \uin\n POSITIVE_COUNT); \uprocedure\n WRITE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE); Operates on a file of mode INOUT_FILE or OUT_FILE. In the case of the first form, sets the index of the given file to the index value given by the parameter TO. Then (for both forms) gives the value of the parameter ITEM to the element whose position in the given file is specified by the current index of the file; finally, increases the current index by one. The exception MODE_ERROR is raised if the mode of the given file is IN_FILE. The \vexception USE_ERROR\v1419. is raised if the capacity of the external file is exceeded. \uprocedure\n SET_INDEX(FILE : \uin\n FILE_TYPE; TO : \uin\n POSITIVE_COUNT); Operates on a file of any mode. Sets the current index of the given file to the given index value (which may exceed the \vcurrent\v1402. \vsize\v1402. of the file). \ufunction\n INDEX(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT; Operates on a file of any mode. Returns the current index of the given file. \ufunction\n SIZE(FILE : \uin\n FILE_TYPE) \ureturn\n \vCOUNT\v1402.; Operates on a file of any mode. Returns the current size of the external file that is associated with the given file. \ufunction\n END_OF_FILE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; Operates on a file of mode IN_FILE or INOUT_FILE. Returns TRUE if the current index exceeds the size of the external file; otherwise returns FALSE. The exception MODE_ERROR is raised if the mode of the given file is OUT_FILE. :1407 14.2.5 \uSpecification of the Package Direct_IO\n \uwith\n \vIO_EXCEPTIONS\v1419.; generic \utype\n \vELEMENT_TYPE\v1406. \uis private\n; \upackage\n DIRECT_IO \uis\n \utype\n \vFILE_TYPE\v1406. \uis limited private\n; \utype\n FILE_MODE \uis\n (\vIN_FILE\v1406., \vINOUT_FILE\v1406., \vOUT_FILE\v1403.); \vtype COUNT\v1402. \uis range\n 0 .. implementation defined; \usubtype\n POSITIVE_COUNT \uis\n COUNT \urange\n 1 .. COUNT'LAST; -- File management \vprocedure CREATE\v1403.(FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE := INOUT_FILE; NAME : \uin\n STRING := ""; FORM : \uin\n STRING := ""); \vprocedure OPEN\v1403. (FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE; NAME : \uin\n STRING; FORM : \uin\n STRING := ""); \vprocedure CLOSE\v1403. (FILE : \uin out\n FILE_TYPE); \vprocedure DELETE\v1403.(FILE : \uin out\n FILE_TYPE); \uprocedure\n RESET (FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE); \uprocedure\n RESET (FILE : \uin out\n FILE_TYPE); \vfunction MODE\v1403. (FILE : \uin\n FILE_TYPE) \ureturn\n FILE_MODE; \vfunction NAME\v1403. (FILE : \uin\n FILE_TYPE) \ureturn\n STRING; \vfunction FORM\v1403. (FILE : \uin\n FILE_TYPE) \ureturn\n STRING; \vfunction IS_OPEN\v1403.(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; -- Input and output operations \vprocedure READ\v1406. (FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE; FROM : POSITIVE_COUNT); \uprocedure\n READ (FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE); \vprocedure WRITE\v1406.(FILE : \uin\n FILE_TYPE; ITEM : \uin \n ELEMENT_TYPE; TO : POSITIVE_COUNT); \uprocedure\n WRITE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE); \vprocedure SET_INDEX\v1406.(FILE : \uin\n FILE_TYPE; TO : \uin\n POSITIVE_COUNT); \vfunction INDEX\v1406.(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT; \vfunction SIZE\v1406. (FILE : \uin\n FILE_TYPE) \ureturn\n COUNT; \vfunction END_OF_FILE\v1406.(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; -- Exceptions \vSTATUS_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.STATUS_ERROR; \vMODE_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.MODE_ERROR; \vNAME_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.NAME_ERROR; \vUSE_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.USE_ERROR; \vDEVICE_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.DEVICE_ERROR; \vEND_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.END_ERROR; \vDATA_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.DATA_ERROR; \uprivate\n -- implementation-dependent \uend\n DIRECT_IO; :1408 14.3 \uText Input-Output\n This section describes the package TEXT_IO, which provides facilities for input and output in human-readable form. Each \vfile\v1401. is \vread\v1404. or written sequentially, as a sequence of characters grouped into lines, and as a sequence of lines grouped into pages. The specification of the package is given below in section 14.3.10. The facilities for file management given above, in sections 14.2.1 and 14.2.2, are available for text input-output. In place of READ and WRITE, however, there are procedures \vGET\v1413. and \vPUT\v1413. that input values of suitable types from text files, and output values to them. These values are provided to the PUT procedures, and returned by the GET procedures, in a parameter ITEM. Several overloaded procedures of these names exist, for different types of ITEM. These GET procedures analyze the input sequences of characters as lexical elements (see Chapter 2) and return the corresponding values; the PUT procedures output the given values as appropriate lexical elements. Procedures GET and PUT are also available that input and output individual characters treated as character values rather than as lexical elements. In addition to the procedures GET and PUT for numeric and enumeration types of ITEM that operate on text files, analogous procedures are provided that read from and write to a parameter of type STRING. These procedures perform the same analysis and composition of character sequences as their counterparts which have a file parameter. For all GET and PUT procedures that operate on text files, and for many other subprograms, there are forms with and without a file parameter. Each such GET procedure operates on an input file, and each such PUT procedure operates on an output file. If no file is specified, a default input file or a default output file is used. At the beginning of program execution the default input and output files are the so-called \vstandard input file\v1410. and \vstandard output file\v1410.. These files are open, have respectively the current modes \vIN_FILE\v1401. and \vOUT_FILE\v1401., and are associated with two implementation-defined \vexternal files\v1401.. Procedures are provided to change the \vcurrent default input file\v1410. and the \vcurrent default output file\v1410.. From a logical point of view, a text file is a sequence of pages, a page is a sequence of lines, and a line is a sequence of characters; the end of a line is marked by a line terminator; the end of a page is marked by the combination of a line terminator immediately followed by a page terminator; and the end of a file is marked by the combination of a line terminator immediately followed by a page terminator and then a file terminator. Terminators are generated during output; either by calls of procedures provided expressly for that purpose; or implicitly as part of other operations, for example, when a bounded line length, a bounded page length, or both, have been specified for a file. The actual nature of terminators is not defined by the language and hence depends on the implementation. Although terminators are recognized or generated by certain of the procedures that follow, they are not necessarily implemented as characters or as sequences of characters. Whether they are characters (and if so which ones) in any particular implementation need not concern a user who neither explicitly outputs nor explicitly inputs control characters. The effect of input or output of control characters (other than horizontal tabulation) is not defined by the language. The characters of a line are numbered, starting from one; the number of a character is called its column number. For a line terminator, a column number is also defined: it is one more than the number of characters in the line. The lines of a page, and the pages of a file, are similarly numbered. The current column number is the column number of the next character or line terminator to be transferred. The current line number is the number of the current line. The current page number is the number of the current page. These numbers are values of the subtype POSITIVE_COUNT of the \vtype COUNT\v1418. (by convention, the value zero of the type COUNT is used to indicate special conditions). type COUNT is range 0 .. implementation_defined; subtype POSITIVE_COUNT is COUNT range 1 .. COUNT'LAST; For an output file, a maximum line length can be specified and a maximum page length can be specified. If a value to be output cannot fit on the current line, for a specified maximum line length, then a new line is automatically started before the value is output; if, further, this new line cannot fit on the current page, for a specified maximum page length, then a new page is automatically started before the value is output. Functions are provided to determine the maximum line length and the maximum page length. When a file is opened with mode OUT_FILE, both values are zero: by convention, this means that the line lengths and page lengths are unbounded. (Consequently, output consists of a single line if the subprograms for explicit control of line and page structure are not used.) The constant UNBOUNDED is provided for this purpose. More details: 14.3.1 \vFile Management\v1409. 14.3.2 \vDefault Input and Output Files\v1410. 14.3.3 \vSpecification of Line and Page Lengths\v1411. 14.3.4 \vOperations on Columns, Lines and Pages\v1412. 14.3.5 \vGET and PUT Procedures\v1413. 14.3.6 \vInput-output of Characters and Strings\v1414. 14.3.7 \vInput-Output for Integer Types\v1415. 14.3.8 \vInput-Output for Real Types\v1416. 14.3.9 \vInput-Output for Enumeration Types\v1417. 14.3.10 \vSpecification of the Package TEXT_IO\v1418. :1409 14.3.1 \uFile Management\n The only allowed \vfile modes\v1401. for text \vfiles\v1401. are the modes \vIN_FILE\v1401. and \vOUT_FILE\v1401.. The subprograms given in section 14.2.1 for the control of \vexternal files\v1401., and the function \vEND_OF_FILE\v1408. given in section 14.2.2 for sequential input-output, are also available for text files. There is also a version of END_OF_FILE that refers to the \vcurrent default input file\v1408.. For text files, the procedures have the following additional effects: - For the procedures \vCREATE\v1403. and \vOPEN\v1403.: After opening a file with mode OUT_FILE, the \vpage length\v1408. and \vline length\v1408. are unbounded (both have the conventional value zero). After opening a file with mode IN_FILE or OUT_FILE, the \vcurrent column\v1408., \vcurrent line\v1408., and \vcurrent page numbers\v1408. are set to one. - For the procedure CLOSE: If the file has the current mode OUT_FILE, has the effect of calling NEW_PAGE, unless the current page is already terminated; then outputs a \vfile terminator\v1408.. - For the \vprocedure RESET\v1403.: If the file has the current mode OUT_FILE, has the effect of calling NEW_PAGE, unless the current page is already terminated; then outputs a file terminator. If the new file mode is OUT_FILE, the page and line lengths are unbounded. For all modes, the current column, line, and page numbers are set to one. The \vexception MODE_ERROR\v1419. is raised by the procedure RESET upon an attempt to change the mode of a file that is either the current default input file, or the current default output file. :1410 14.3.2 \uDefault Input and Output Files\n The following subprograms provide for the control of the particular \vdefault\v1408. \vfiles\v1408. that are used when a file parameter is omitted from a \vGET\v1413., \vPUT\v1413. or other operation of text input-output described below. \uprocedure\n SET_INPUT(FILE : \uin\n \vFILE_TYPE\v1401.); Operates on a file of mode IN_FILE. Sets the current default input file to FILE. The \vexception STATUS_ERROR\v1419. is raised if the given file is not open. The \vexception MODE_ERROR\v1419. is raised if the mode of the given file is not IN_FILE. \uprocedure\n SET_OUTPUT(FILE : \uin\n FILE_TYPE); Operates on a file of mode OUT_FILE. Sets the current default output file to FILE. The exception STATUS_ERROR is raised if the given file is not open. The exception MODE_ERROR is raised if the mode of the given file is not OUT_FILE. \ufunction\n STANDARD_INPUT \ureturn\n FILE_TYPE; Returns the standard input file (see 14.3). \ufunction\n STANDARD_OUTPUT \ureturn\n FILE_TYPE; Returns the standard output file (see 14.3). \ufunction\n CURRENT_INPUT \ureturn\n FILE_TYPE; Returns the current default input file. \ufunction\n CURRENT_OUTPUT \ureturn\n FILE_TYPE; Returns the current default output file. Note: The standard input and the standard output files cannot be opened, closed, reset, or deleted, because the parameter FILE of the corresponding procedures has the mode in out. :1411 14.3.3 \uSpecification of Line and Page Lengths\n The subprograms described in this section are concerned with the \vline\v1408. and \vpage\v1408. structure of a \vfile\v1401. of mode \vOUT_FILE\v1401.. They operate either on the file given as the first parameter, or, in the absence of such a file parameter, on the \vcurrent default output file\v1408.. They provide for output of text with a specified \vmaximum line length\v1408. or \vpage length\v1408.. In these cases, \vline\v1408. and \vpage terminators\v1408. are output implicitly and automatically when needed. When \vline\v1408. and \vpage lengths\v1408. are unbounded (that is, when they have the conventional value zero), as in the case of a newly opened file, new lines and new pages are only started when explicitly called for. In all cases, the \vexception STATUS_ERROR\v1419. is raised if the file to be used is not \vopen\v1401.; the \vexception MODE_ERROR\v1419. is raised if the mode of the file is not OUT_FILE. \uprocedure\n SET_LINE_LENGTH(FILE : \uin\n \vFILE_TYPE\v1401.; TO : \uin\n \vCOUNT\v1408.); \uprocedure\n SET_LINE_LENGTH(TO : \uin\n COUNT); Sets the maximum line length of the specified output file to the number of characters specified by TO. The value zero for TO specifies an unbounded line length. The \vexception USE_ERROR\v1419. is raised if the specified line length is inappropriate for the associated \vexternal file\v1401.. \uprocedure\n SET_PAGE_LENGTH(FILE : \uin\n FILE_TYPE; TO : \uin\n COUNT); \uprocedure\n SET_PAGE_LENGTH(TO : \uin\n COUNT); Sets the maximum page length of the specified output file to the number of lines specified by TO. The value zero for TO specifies an \vunbounded page length\v1408.. The exception USE_ERROR is raised if the specified page length is inappropriate for the associated external file. \ufunction\n LINE_LENGTH(FILE : \uin\n FILE_TYPE) \ureturn\n COUNT; \ufunction\n LINE_LENGTH \ureturn\n COUNT; Returns the maximum line length currently set for the specified output file, or zero if the line length is unbounded. \ufunction\n PAGE_LENGTH(FILE : \uin\n FILE_TYPE) \ureturn\n COUNT; \ufunction\n PAGE_LENGTH \ureturn\n COUNT; Returns the maximum page length currently set for the specified output file, or zero if the page length is unbounded. :1412 14.3.4 \uOperations on Columns, Lines, and Pages\n The subprograms described in this section provide for explicit control of \vline\v1408. and \vpage\v1408. structure; they operate either on the \vfile\v1401. given as the first parameter, or, in the absence of such a file parameter, on the appropriate (input or output) \vcurrent default file\v1408.. The \vexception\v1419. \vSTATUS_ERROR\v1419. is raised by any of these subprograms if the file to be used is not \vopen\v1401.. \uprocedure\n NEW_LINE(FILE : \uin\n FILE_TYPE; SPACING : \uin\n \vPOSITIVE_COUNT\v1408. := 1); \uprocedure\n NEW_LINE(SPACING : \uin\n POSITIVE_COUNT := 1); Operates on a file of mode OUT_FILE. For a SPACING of one: Outputs a \vline terminator\v1408. and sets the \vcurrent column number\v1408. to one. Then increments the \vcurrent line\v1408. \vnumber\v1408. by one, except in the case that the current \vline number\v1408. is already greater than or equal to the \vmaximum page length\v1408., for a bounded \vpage length\v1408.; in that case a \vpage terminator\v1408. is output, the \vcurrent page number\v1408. is incremented by one, and the current line number is set to one. For a SPACING greater than one, the above actions are performed SPACING times. The \vexception MODE_ERROR\v1419. is raised if the mode is not OUT_FILE. \uprocedure\n SKIP_LINE(FILE : \uin\n FILE_TYPE; SPACING : \uin\n POSITIVE_COUNT := 1); \uprocedure\n SKIP_LINE(SPACING : \uin\n POSITIVE_COUNT := 1); Operates on a file of mode \vIN_FILE\v1401.. For a SPACING of one: Reads and discards all characters until a line terminator has been read, and then sets the current column number to one. If the line terminator is not immediately followed by a page terminator, the current line number is incremented by one. Otherwise, if the line terminator is immediately followed by a page terminator, then the page terminator is skipped, the current page number is incremented by one, and the current line number is set to one. For a SPACING greater than one, the above actions are performed SPACING times. The exception MODE_ERROR is raised if the mode is not IN_FILE. The \vexception END_ERROR\v1419. is raised if an attempt is made to read a \vfile terminator\v1408.. \ufunction\n END_OF_LINE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; \ufunction\n END_OF_LINE \ureturn\n BOOLEAN; Operates on a file of mode IN_FILE. Returns TRUE if a line terminator or a file terminator is next; otherwise returns FALSE. The exception MODE_ERROR is raised if the mode is not IN_FILE. \uprocedure\n NEW_PAGE(FILE : \uin\n FILE_TYPE); \uprocedure\n NEW_PAGE; Operates on a file of mode OUT_FILE. Outputs a line terminator if the current line is not terminated, or if the current page is empty (that is, if the current column and line numbers are both equal to one). Then outputs a page terminator, which terminates the current page. Adds one to the current page number and sets the current column and line numbers to one. The exception MODE_ERROR is raised if the mode is not OUT_FILE. \uprocedure\n SKIP_PAGE(FILE: \uin\n FILE_TYPE); \uprocedure\n SKIP_PAGE; Operates on a file of mode IN_FILE. Reads and discards all characters and line terminators until a page terminator has been read. Then adds one to the current page number, and sets the current column and line numbers to one. The exception MODE_ERROR is raised if the mode is not IN_FILE. The exception END_ERROR is raised if an attempt is made to read a file terminator. \ufunction\n END_OF_PAGE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; \ufunction\n END_OF_PAGE \ureturn\n BOOLEAN; Operates on a file of mode IN_FILE. Returns TRUE if the combination of a line terminator and a page terminator is next, or if a file terminator is next; otherwise returns FALSE. The exception MODE_ERROR is raised if the mode is not IN_FILE. \ufunction\n END_OF_FILE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN; \ufunction\n END_OF_FILE \ureturn\n BOOLEAN; Operates on a file of mode IN_FILE. Returns TRUE if a file terminator is next, or if the combination of a line, a page, and a file terminator is next; otherwise returns FALSE. The exception MODE_ERROR is raised if the mode is not IN_FILE. The following subprograms provide for the control of the current position of reading or writing in a file. In all cases, the default file is the current output file. \uprocedure\n SET_COL(FILE : \uin\n FILE_TYPE; TO : \uin\n POSITIVE_COUNT); \uprocedure\n SET_COL(TO : \uin\n POSITIVE_COUNT); If the file mode is OUT_FILE: If the value specified by TO is greater than the current column number, outputs spaces, adding one to the current column number after each space, until the current column number equals the specified value. If the value specified by TO is equal to the current column number, there is no effect. If the value specified by TO is less than the current column number, has the effect of calling NEW_LINE (with a spacing of one), then outputs (TO - 1) spaces, and sets the current column number to the specified value. The \vexception LAYOUT_ERROR\v1419. is raised if the value specified by TO exceeds LINE_LENGTH when the line length is bounded (that is, when it does not have the conventional value zero). If the file mode is IN_FILE: Reads (and discards) individual characters, line terminators, and page terminators, until the next character to be read has a column number that equals the value specified by TO; there is no effect if the current column number already equals this value. Each transfer of a character or terminator maintains the current column, line, and page numbers in the same way as a \vGET procedure\v1413. (see 14.3.5). (Short lines will be skipped until a line is reached that has a character at the specified column position.) The exception END_ERROR is raised if an attempt is made to read a file terminator. \uprocedure\n SET_LINE(FILE : \uin\n FILE_TYPE; TO : \uin\n POSITIVE_COUNT); \uprocedure\n SET_LINE(TO : \uin\n POSITIVE_COUNT); If the file mode is OUT_FILE: If the value specified by TO is greater than the current line number, has the effect of repeatedly calling NEW_LINE (with a spacing of one), until the current line number equals the specified value. If the value specified by TO is equal to the current line number, there is no effect. If the value specified by TO is less than the current line number, has the effect of calling NEW_PAGE followed by a call of NEW_LINE with a spacing equal to (TO - 1). The exception LAYOUT_ERROR is raised if the value specified by TO exceeds PAGE_LENGTH when the page length is bounded (that is, when it does not have the conventional value zero). If the mode is IN_FILE: Has the effect of repeatedly calling SKIP_LINE (with a spacing of one), until the current line number equals the value specified by TO; there is no effect if the current line number already equals this value. (Short pages will be skipped until a page is reached that has a line at the specified line position.) The exception END_ERROR is raised if an attempt is made to read a file terminator. \ufunction\n COL(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT; \ufunction\n COL \ureturn\n POSITIVE_COUNT; Returns the current column number. The exception LAYOUT_ERROR is raised if this number exceeds COUNT'LAST. \ufunction\n LINE(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT; \ufunction\n LINE \ureturn\n POSITIVE_COUNT; Returns the current line number. The exception LAYOUT_ERROR is raised if this number exceeds COUNT'LAST. \ufunction\n PAGE(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT; \ufunction\n PAGE \ureturn\n POSITIVE_COUNT; Returns the current page number. The exception LAYOUT_ERROR is raised if this number exceeds COUNT'LAST. The column number, line number, or page number are allowed to exceed COUNT'LAST (as a consequence of the input or output of sufficiently many characters, lines, or pages). These events do not cause any exception to be raised. However, a call of COL, LINE, or PAGE raises the exception LAYOUT_ERROR if the corresponding number exceeds COUNT'LAST. Note: A page terminator is always skipped whenever the preceding line terminator is skipped. An implementation may represent the combination of these terminators by a single character, provided that it is properly recognized at input. :1413 14.3.5 \uGet and Put Procedures\n The procedures \vGET\v1414. and \vPUT\v1414. for items of the types CHARACTER, STRING, numeric types, and enumeration types are described in subsequent sections. Features of these procedures that are common to most of these types are described in this section. The GET and PUT procedures for items of type CHARACTER and STRING deal with individual character values; the GET and PUT procedures for numeric and enumeration types treat the items as lexical elements. All procedures GET and PUT have forms with a file parameter, written first. Where this parameter is omitted, the appropriate (input or output) \vcurrent\v1408. \vdefault file\v1408. is understood to be specified. Each procedure GET operates on a \vfile\v1401. of mode \vIN_FILE\v1401.. Each procedure PUT operates on a file of mode \vOUT_FILE\v1401.. All procedures GET and PUT maintain the current column, line, and page numbers of the specified file: the effect of each of these procedures upon these numbers is the resultant of the effects of individual transfers of characters and of individual output or \vskipping\v1415. of terminators. Each transfer of a character adds one to the current \vcolumn number\v1408.. Each output of a \vline terminator\v1401. sets the current column number to one and adds one to the current \vline number\v1401.. Each output of a \vpage terminator\v1401. sets the current column and line numbers to one and adds one to the current \vpage\v1401. \vnumber\v1401.. For input, each skipping of a line terminator sets the current column number to one and adds one to the current line number; each skipping of a page terminator sets the current column and line numbers to one and adds one to the current page number. Similar considerations apply to the procedures GET_LINE, PUT_LINE, and SET_COL. Several GET and PUT procedures, for numeric and enumeration types, have format parameters which specify field lengths; these parameters are of the nonnegative subtype FIELD of the type INTEGER. Input-output of enumeration values uses the syntax of the corresponding lexical elements. Any GET procedure for an enumeration type begins by skipping any leading \vblanks\v1417., or line or page terminators; a blank being defined as a space or a horizontal tabulation character. Next, characters are input only so long as the sequence input is an initial sequence of an identifier or of a character literal (in particular, input ceases when a line terminator is encountered). The character or line terminator that causes input to cease remains available for subsequent input. For a numeric type, the GET procedures have a format parameter called \vWIDTH\v1413.. If the value given for this parameter is zero, the GET procedure proceeds in the same manner as for enumeration types, but using the syntax of numeric literals instead of that of enumeration literals. If a nonzero value is given, then exactly WIDTH characters are input, or the characters up to a line terminator, whichever comes first; any skipped leading blanks are included in the count. The syntax used for numeric literals is an extended syntax that allows a leading sign (but no intervening blanks, or line or page terminators). Any PUT procedure, for an item of a numeric or an enumeration type, outputs the value of the item as a numeric literal, identifier, or character literal, as appropriate. This is preceded by leading spaces if required by the format parameters WIDTH or \vFORE\v1416. (as described in later sections), and then a minus sign for a negative value; for an enumeration type, the spaces follow instead of leading. The format given for a PUT procedure is overridden if it is insufficiently wide. Two further cases arise for PUT procedures for numeric and enumeration types, if the line length of the specified output file is bounded (that is, if it does not have the conventional value zero). If the number of characters to be output does not exceed the \vmaximum line length\v1408., but is such that they cannot fit on the current line, starting from the current column, then (in effect) NEW_LINE is called (with a spacing of one) before output of the item. Otherwise, if the number of characters exceeds the maximum line length, then the \vexception LAYOUT_ERROR\v1419. is raised and no characters are output. The \vexception STATUS_ERROR\v1419. is raised by any of the procedures GET, GET_LINE, PUT, and PUT_LINE if the file to be used is not open. The \vexception MODE_ERROR\v1419. is raised by the procedures GET and GET_LINE if the \vmode\v1401. of the file to be used is not IN_FILE; and by the procedures PUT and PUT_LINE, if the mode is not OUT_FILE. The \vexception END_ERROR\v1419. is raised by a GET procedure if an attempt is made to skip a file terminator. The \vexception DATA_ERROR\v1419. is raised by a GET procedure if the sequence finally input is not a lexical element corresponding to the type, in particular if no characters were input; for this test, leading blanks are ignored; for an item of a numeric type, when a sign is input, this rule applies to the succeeding numeric literal. The exception LAYOUT_ERROR is raised by a PUT procedure that outputs to a parameter of type STRING, if the length of the actual string is insufficient for the output of the item. \uExamples:\n In the examples, here and in sections 14.3.7 and 14.3.8, the string quotes and the lower case letter b are not transferred: they are shown only to reveal the layout and spaces. N : INTEGER; ... GET(N); -- Characters at input Sequence input Value of N -- bb-12535b -12535 -12535 -- bb12_535E1b 12_535E1 125350 -- bb12_535E; 12_535E (none) DATA_ERROR raised Example of overridden width parameter: PUT(ITEM => -23, WIDTH => 2); -- "-23" :1414 14.3.6 \uInput-Output of Characters and Strings\n For an item of type CHARACTER the following procedures are provided: \vprocedure GET\v1413.(\vFILE\v1401. : in FILE_TYPE; ITEM : out CHARACTER); procedure GET(ITEM : out CHARACTER); After \vskipping\v1413. any line terminators and any \vpage terminators\v1408., reads the next character from the specified input file and returns the value of this character in the out parameter ITEM. The \vexception END_ERROR\v1419. is raised if an attempt is made to skip a \vfile terminator\v1408.. \vprocedure PUT\v1412.(FILE : in FILE_TYPE; ITEM : in CHARACTER); procedure PUT(ITEM : in CHARACTER); If the \vline length\v1408. of the specified output file is bounded (that is, does not have the conventional value zero), and the \vcurrent\v1408. \vcolumn number\v1408. exceeds it, has the effect of calling NEW_LINE with a spacing of one. Then, or otherwise, outputs the given character to the file. For an item of type STRING the following procedures are provided: \uprocedure\n GET(FILE : \uin\n FILE_TYPE; ITEM : \uout\n STRING); \uprocedure\n GET(ITEM : \uout\n STRING); Determines the length of the given string and attempts that number of GET operations for successive characters of the string (in particular, no operation is performed if the string is null). \uprocedure\n PUT(FILE : \uin\n FILE_TYPE; ITEM : \uin\n STRING); \uprocedure\n PUT(ITEM : \uin\n STRING); Determines the length of the given string and attempts that number of PUT operations for successive characters of the string (in particular, no operation is performed if the string is null). \uprocedure\n GET_LINE(FILE : \uin\n FILE_TYPE; ITEM : \uout\n STRING; LAST : \uout\n NATURAL); \uprocedure\n GET_LINE(ITEM : \uout\n STRING; LAST : \uout\n NATURAL); Replaces successive characters of the specified string by successive characters read from the specified input file. Reading stops if the end of the \vline\v1408. is met, in which case the procedure SKIP_LINE is then called (in effect) with a spacing of one; reading also stops if the end of the string is met. Characters not replaced are left undefined. If characters are read, returns in LAST the index value such that ITEM(LAST) is the last character replaced (the index of the first character replaced is ITEM'FIRST). If no characters are read, returns in LAST an index value that is one less than ITEM'FIRST. The exception END_ERROR is raised if an attempt is made to skip a file terminator. \uprocedure\n PUT_LINE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n STRING); \uprocedure\n PUT_LINE(ITEM : \uin\n STRING); Calls the procedure PUT for the given string, and then the \vprocedure NEW_LINE\v1412. with a spacing of one. \uNotes:\n In a literal string parameter of PUT, the enclosing string bracket characters are not output. Each doubled string bracket character in the enclosed string is output as a single string bracket character, as a consequence of the rule for string literals (see 2.6). A string read by GET or written by PUT can extend over several lines. :1415 14.3.7 \uInput-Output for Integer Types\n The following procedures are defined in the generic \vpackage INTEGER_IO\v1418.. This must be instantiated for the appropriate integer type (indicated by NUM in the specification). Values are output as \vdecimal\v205. or \vbased literals\v206., without underline characters or exponent, and preceded by a minus sign if negative. The format (which includes any leading spaces and minus sign) can be specified by an optional field \vwidth\v1413. parameter. Values of widths of fields in output formats are of the nonnegative integer subtype \vFIELD\v1413.. Values of bases are of the integer subtype NUMBER_BASE. \usubtype\n NUMBER_BASE \uis\n INTEGER \urange\n 2 .. 16; The default field width and base to be used by output procedures are defined by the following variables that are declared in the generic package INTEGER_IO: DEFAULT_WIDTH : FIELD := NUM'WIDTH; DEFAULT_BASE : NUMBER_BASE := 10; The following procedures are provided: \vprocedure GET\v1413.(FILE : in \vFILE_TYPE\v1401.; ITEM : out NUM; WIDTH : in FIELD := 0); procedure GET(ITEM : out NUM; WIDTH : in FIELD := 0); If the value of the parameter WIDTH is zero, skips any leading \vblanks\v1413., \vline terminators\v1408., or page terminators, then reads a plus or a minus sign if present, then reads according to the syntax of an \vinteger literal\v204. (which may be a based literal). If a nonzero value of WIDTH is supplied, then exactly WIDTH characters are input, or the characters (possibly none) up to a line terminator, whichever comes first; any skipped leading blanks are included in the count. Returns, in the parameter ITEM, the value of type NUM that corresponds to the sequence input. The \vexception DATA_ERROR\v1419. is raised if the sequence input does not have the required syntax or if the value obtained is not of the subtype NUM. \vprocedure PUT\v1413.(FILE : \uin\n FILE_TYPE; ITEM : \uin\n NUM; WIDTH : \uin\n FIELD := DEFAULT_WIDTH; BASE : \uin\n NUMBER_BASE := DEFAULT_BASE); \uprocedure\n PUT(ITEM : \uin\n NUM; WIDTH : \uin\n FIELD := DEFAULT_WIDTH; BASE : \uin\n NUMBER_BASE := DEFAULT_BASE); Outputs the value of the parameter ITEM as an integer literal, with no underlines, no exponent, and no leading zeros (but a single zero for the value zero), and a preceding minus sign for a negative value. If the resulting sequence of characters to be output has fewer than WIDTH characters, then leading spaces are first output to make up the difference. Uses the syntax for decimal literal if the parameter BASE has the value ten (either explicitly or through DEFAULT_BASE); otherwise, uses the syntax for based literal, with any letters in upper case. procedure GET(FROM : in STRING; ITEM : out NUM; LAST : out POSITIVE); Reads an integer value from the beginning of the given string, following the same rules as the GET procedure that reads an integer value from a file, but treating the end of the string as a file terminator. Returns, in the parameter ITEM, the value of type NUM that corresponds to the sequence input. Returns in LAST the index value such that FROM(LAST) is the last character read. The exception DATA_ERROR is raised if the sequence input does not have the required syntax or if the value obtained is not of the subtype NUM. \uprocedure\n PUT(TO : \uout\n STRING; ITEM : \uin\n NUM; BASE : \uin\n NUMBER_BASE := DEFAULT_BASE); Outputs the value of the parameter ITEM to the given string, following the same rule as for output to a file, using the length of the given string as the value for WIDTH. \uExamples:\n \upackage\n INT_IO \uis new\n INTEGER_IO(SMALL_INT); \uuse\n INT_IO; -- default format used at instantiation, DEFAULT_WIDTH = 4, DEFAULT_BASE = 10 PUT(126); -- "b126" PUT(-126, 7); -- "bbb-126" PUT(126, WIDTH => 13, BASE => 2); -- "bbb2#1111110#" :1416 14.3.8 \uInput-Output for Real Types\n The following procedures are defined in the generic packages \vFLOAT_IO\v1418. and \vFIXED_IO\v1418., which must be instantiated for the appropriate floating point or fixed point type respectively (indicated by NUM in the specifications). Values are output as \vdecimal literals\v205. without underline characters. The format of each value output consists of a \vFORE\v320. field, a decimal point, an \vAFT\v320. field, and (if a nonzero EXP parameter is supplied) the letter E and an EXP field. The two possible formats thus correspond to: FORE . AFT and to: FORE . AFT E EXP without any spaces between these fields. The FORE field may include leading spaces, and a minus sign for negative values. The AFT field includes only decimal digits (possibly with trailing zeros). The EXP field includes the sign (plus or minus) and the exponent (possibly with leading zeros). For floating point types, the default lengths of these fields are defined by the following variables that are declared in the generic package FLOAT_IO: DEFAULT_FORE : \vFIELD\v1413. := 2; DEFAULT_AFT : FIELD := NUM'DIGITS-1; DEFAULT_EXP : FIELD := 3; For fixed point types, the default lengths of these fields are defined by the following variables that are declared in the generic package FIXED_IO: DEFAULT_FORE : FIELD := NUM'FORE; DEFAULT_AFT : FIELD := NUM'AFT; DEFAULT_EXP : FIELD := 0; The following procedures are provided: \vprocedure GET\v1413.(FILE : \uin\n \vFILE_TYPE\v1401.; ITEM : \uout\n NUM; \vWIDTH\v1413. : \uin\n FIELD := 0); \uprocedure\n GET(ITEM : \uout\n NUM; WIDTH : \uin\n FIELD := 0); If the value of the parameter WIDTH is zero, skips any leading \vblanks\v1413., \vline terminators\v1413., or page terminators, then reads a plus or a minus sign if present, then reads according to the syntax of a \vreal literal\v204. (which may be a \vbased literal\v206.). If a nonzero value of WIDTH is supplied, then exactly WIDTH characters are input, or the characters (possibly none) up to a line terminator, whichever comes first; any skipped leading blanks are included in the count. Returns, in the parameter ITEM, the value of type NUM that corresponds to the sequence input. The \vexception DATA_ERROR\v1413. is raised if the sequence input does not have the required syntax or if the value obtained is not of the subtype NUM. \vprocedure PUT\v1413.(FILE : \uin\n FILE_TYPE; ITEM : \uin\n NUM; FORE : \uin\n FIELD := DEFAULT_FORE; AFT : \uin\n FIELD := DEFAULT_AFT; EXP : \uin\n FIELD := DEFAULT_EXP); \uprocedure\n PUT(ITEM : \uin\n NUM; FORE : \uin\n FIELD := DEFAULT_FORE; AFT : \uin\n FIELD := DEFAULT_AFT; EXP : \uin\n FIELD := DEFAULT_EXP); Outputs the value of the parameter ITEM as a decimal literal with the format defined by FORE, AFT and EXP. If the value is negative, a minus sign is included in the integer part. If EXP has the value zero, then the integer part to be output has as many digits as are needed to represent the integer part of the value of ITEM, overriding FORE if necessary, or consists of the digit zero if the value of ITEM has no integer part. If EXP has a value greater than zero, then the integer part to be output has a single digit, which is nonzero except for the value 0.0 of ITEM. In both cases, however, if the integer part to be output has fewer than FORE characters, including any minus sign, then leading spaces are first output to make up the difference. The number of digits of the fractional part is given by AFT, or is one if AFT equals zero. The value is rounded; a value of exactly one half in the last place may be rounded either up or down. If EXP has the value zero, there is no exponent part. If EXP has a value greater than zero, then the exponent part to be output has as many digits as are needed to represent the exponent part of the value of ITEM (for which a single digit integer part is used), and includes an initial sign (plus or minus). If the exponent part to be output has fewer than EXP characters, including the sign, then leading zeros precede the digits, to make up the difference. For the value 0.0 of ITEM, the exponent has the value zero. \uprocedure\n GET(FROM : \uin\n STRING; ITEM : \uout\n NUM; LAST : \uout\n POSITIVE); Reads a real value from the beginning of the given string, following the same rule as the GET procedure that reads a real value from a file, but treating the end of the string as a file terminator. Returns, in the parameter ITEM, the value of type NUM that corresponds to the sequence input. Returns in LAST the index value such that FROM(LAST) is the last character read. The exception DATA_ERROR is raised if the sequence input does not have the required syntax, or if the value obtained is not of the subtype NUM. \uprocedure\n PUT(TO : \uout\n STRING; ITEM : \uin\n NUM; AFT : \uin\n FIELD := DEFAULT_AFT; EXP : \uin\n INTEGER := DEFAULT_EXP); Outputs the value of the parameter ITEM to the given string, following the same rule as for output to a file, using a value for FORE such that the sequence of characters output exactly fills the string, including any leading spaces. \uExamples:\n \upackage\n REAL_IO \uis new\n FLOAT_IO(REAL); \uuse\n REAL_IO; -- default format used at instantiation, DEFAULT_EXP = 3 X : REAL := -123.4567; -- digits 8 (see 3.5.7) PUT(X); -- default format "-1.2345670E+02" PUT(X, FORE => 5, AFT => 3, EXP => 2); -- "bbb-1.235E+2" PUT(X, 5, 3, 0); -- "b-123.457" Note: For an item with a positive value, if output to a string exactly fills the string without leading spaces, then output of the corresponding negative value will raise \vLAYOUT_ERROR\v1413.. :1417 14.3.9 \uInput-Output for Enumeration Types\n The following procedures are defined in the generic \vpackage ENUMERATION_IO\v1418., which must be instantiated for the appropriate enumeration type (indicated by ENUM in the specification). Values are output using either upper or lower case letters for identifiers. This is specified by the parameter SET, which is of the enumeration type TYPE_SET. \utype\n TYPE_SET \uis\n (LOWER_CASE, UPPER_CASE); The format (which includes any trailing spaces) can be specified by an optional field \vwidth\v1413. parameter. The default field width and letter case are defined by the following variables that are declared in the generic package ENUMERATION_IO: DEFAULT_WIDTH : \vFIELD\v1413. := 0; DEFAULT_SETTING : TYPE_SET := UPPER_CASE; The following procedures are provided: \vprocedure GET\v1413.(FILE : \uin\n \vFILE_TYPE\v1401.; ITEM : \uout\n ENUM); \uprocedure\n GET(ITEM : \uout\n ENUM); After \vskipping\v1413. any leading \vblanks\v1413., \vline terminators\v1413., or page terminators, reads an identifier according to the syntax of this lexical element (lower and upper case being considered equivalent), or a character literal according to the syntax of this lexical element (including the apostrophes). Returns, in the parameter ITEM, the value of type ENUM that corresponds to the sequence input. The exception \vDATA_ERROR\v1413. is raised if the sequence input does not have the required syntax, or if the identifier or character literal does not correspond to a value of the subtype ENUM. \vprocedure PUT\v1413.(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ENUM; WIDTH : \uin\n FIELD := DEFAULT_WIDTH; SET : \uin\n TYPE_SET := DEFAULT_SETTING); \uprocedure\n PUT(ITEM : \uin\n ENUM; WIDTH : \uin\n FIELD := DEFAULT_WIDTH; SET : \uin\n TYPE_SET := DEFAULT_SETTING); Outputs the value of the parameter ITEM as an enumeration literal (either an identifier or a character literal). The optional parameter SET indicates whether lower case or upper case is used for identifiers; it has no effect for character literals. If the sequence of characters produced has fewer than WIDTH characters, then trailing spaces are finally output to make up the difference. \uprocedure\n GET(FROM : \uin\n STRING; ITEM : \uout\n ENUM; LAST : \uout\n POSITIVE); Reads an enumeration value from the beginning of the given string, following the same rule as the GET procedure that reads an enumeration value from a file, but treating the end of the string as a file terminator. Returns, in the parameter ITEM, the value of type ENUM that corresponds to the sequence input. Returns in LAST the index value such that FROM(LAST) is the last character read. The exception DATA_ERROR is raised if the sequence input does not have the required syntax, or if the identifier or character literal does not correspond to a value of the subtype ENUM. \uprocedure\n PUT(TO : \uout\n STRING; ITEM : \uin\n ENUM; SET : \uin\n TYPE_SET := DEFAULT_SETTING); Outputs the value of the parameter ITEM to the given string, following the same rule as for output to a file, using the length of the given string as the value for WIDTH. Although the specification of the package ENUMERATION_IO would allow instantiation for an integer type, this is not the intended purpose of this generic package, and the effect of such instantiations is not defined by the language. \uNotes:\n There is a difference between PUT defined for characters, and for enumeration values. Thus TEXT_IO.PUT('A'); -- outputs the character A package CHAR_IO is new TEXT_IO.ENUMERATION_IO(CHARACTER); CHAR_IO.PUT('A'); -- outputs the character 'A', between single quotes The type BOOLEAN is an enumeration type, hence ENUMERATION_IO can be instantiated for this type. :1418 14.3.10 \uSpecification of the Package Text_IO\n \uwith\n IO_EXCEPTIONS; \upackage\n TEXT_IO \uis\n \utype\n FILE_TYPE \uis limited private\n; \utype\n FILE_MODE \uis\n (IN_FILE, OUT_FILE); \utype\n COUNT \uis range\n 0 .. implementation defined; \usubtype\n POSITIVE_COUNT is COUNT \urange\n 1 .. COUNT'LAST; UNBOUNDED : \uconstant\n COUNT := 0; -- line and page length \usubtype\n FIELD \uis\n INTEGER \urange\n 0 .. implementation defined; \usubtype\n NUMBER_BASE \uis\n INTEGER \urange\n 2 .. 16; \utype\n TYPE_SET \uis\n (LOWER_CASE, UPPER_CASE); -- File Management procedure CREATE (FILE : in out FILE_TYPE; MODE : in FILE_MODE := OUT_FILE; NAME : in STRING := ""; FORM : in STRING := ""); procedure OPEN (FILE : in out FILE_TYPE; MODE : in FILE_MODE; NAME : in STRING; FORM : in STRING := ""); procedure CLOSE (FILE : in out FILE_TYPE); procedure DELETE (FILE : in out FILE_TYPE); procedure RESET (FILE : in out FILE_TYPE; MODE : in FILE_MODE); procedure RESET (FILE : in out FILE_TYPE); function MODE (FILE : in FILE_TYPE) return FILE_MODE; function NAME (FILE : in FILE_TYPE) return STRING; function FORM (FILE : in FILE_TYPE) return STRING; function IS_OPEN(FILE : in FILE_TYPE) return BOOLEAN; -- Control of default input and output files procedure SET_INPUT (FILE : in FILE_TYPE); procedure SET_OUTPUT(FILE : in FILE_TYPE); function STANDARD_INPUT return FILE_TYPE; function STANDARD_OUTPUT return FILE_TYPE; function CURRENT_INPUT return FILE_TYPE; function CURRENT_OUTPUT return FILE_TYPE; -- Specification of line and page lengths procedure SET_LINE_LENGTH(FILE : in FILE_TYPE; TO : in COUNT); procedure SET_LINE_LENGTH(TO : in COUNT); procedure SET_PAGE_LENGTH(FILE : in FILE_TYPE; TO : in COUNT); procedure SET_PAGE_LENGTH(TO : in COUNT); function LINE_LENGTH(FILE : in FILE_TYPE) return COUNT; function LINE_LENGTH return COUNT; function PAGE_LENGTH(FILE : in FILE_TYPE) return COUNT; function PAGE_LENGTH return COUNT; -- Column, Line, and Page Control procedure NEW_LINE (FILE : in FILE_TYPE; SPACING : in POSITIVE_COUNT := 1); procedure NEW_LINE (SPACING : in POSITIVE_COUNT := 1); procedure SKIP_LINE (FILE : in FILE_TYPE; SPACING :in POSITIVE_COUNT := 1); procedure SKIP_LINE (SPACING : in POSITIVE_COUNT := 1); function END_OF_LINE(FILE : in FILE_TYPE) return BOOLEAN; function END_OF_LINE return BOOLEAN; procedure NEW_PAGE (FILE : in FILE_TYPE); procedure NEW_PAGE; procedure SKIP_PAGE (FILE : in FILE_TYPE); procedure SKIP_PAGE; function END_OF_PAGE(FILE : in FILE_TYPE) return BOOLEAN; function END_OF_PAGE return BOOLEAN; function END_OF_FILE(FILE : in FILE_TYPE) return BOOLEAN; function END_OF_FILE return BOOLEAN; procedure SET_COL (FILE : in FILE_TYPE; TO : in POSITIVE_COUNT); procedure SET_COL (TO : in POSITIVE_COUNT); procedure SET_LINE(FILE : in FILE_TYPE; TO : in POSITIVE_COUNT); procedure SET_LINE(TO : in POSITIVE_COUNT); function COL (FILE : in FILE_TYPE) return POSITIVE_COUNT; function COL return POSITIVE_COUNT; function LINE(FILE : in FILE_TYPE) return POSITIVE_COUNT; function LINE return POSITIVE_COUNT; function PAGE(FILE : in FILE_TYPE) return POSITIVE_COUNT; function PAGE return POSITIVE_COUNT; -- Character Input-Output procedure GET(FILE : in FILE_TYPE; ITEM : out CHARACTER); procedure GET(ITEM : out CHARACTER); procedure PUT(FILE : in FILE_TYPE; ITEM : in CHARACTER); procedure PUT(ITEM : in CHARACTER); -- String Input-Output procedure GET(FILE : in FILE_TYPE; ITEM : out STRING); procedure GET(ITEM : out STRING); procedure PUT(FILE : in FILE_TYPE; ITEM : in STRING); procedure PUT(ITEM : in STRING); procedure GET_LINE(FILE : in FILE_TYPE; ITEM : out STRING; LAST : out NATURAL); procedure GET_LINE(ITEM : out STRING; LAST : out NATURAL); procedure PUT_LINE(FILE : in FILE_TYPE; ITEM : in STRING); procedure PUT_LINE(ITEM : in STRING); -- Generic package for Input-Output of Integer Types generic type NUM is range <>; package INTEGER_IO is DEFAULT_WIDTH : FIELD := NUM'WIDTH; DEFAULT_BASE : NUMBER_BASE := 10; procedure GET(FILE : in FILE_TYPE; ITEM : out NUM; WIDTH : in FIELD := 0); procedure GET(ITEM : out NUM; WIDTH : in FIELD := 0); procedure PUT(FILE : in FILE_TYPE; ITEM : in NUM; WIDTH : in FIELD := DEFAULT_WIDTH; BASE : in NUMBER_BASE := DEFAULT_BASE); procedure PUT(ITEM : in NUM; WIDTH : in FIELD := DEFAULT_WIDTH; BASE : in NUMBER_BASE := DEFAULT_BASE); procedure GET(FROM : in STRING; ITEM : out NUM; LAST : out POSITIVE); procedure PUT(TO : out STRING; ITEM : in NUM; BASE : in NUMBER_BASE := DEFAULT_BASE); end INTEGER_IO; -- Generic packages for Input-Output of Real Types generic type NUM is digits <>; package FLOAT_IO is DEFAULT_FORE : FIELD := 2; DEFAULT_AFT : FIELD := NUM'DIGITS-1; DEFAULT_EXP : FIELD := 3; procedure GET(FILE : in FILE_TYPE; ITEM : out NUM; WIDTH : in FIELD := 0); procedure GET(ITEM : out NUM; WIDTH : in FIELD := 0); procedure PUT(FILE : in FILE_TYPE; ITEM : in NUM; FORE : in FIELD := DEFAULT_FORE; AFT : in FIELD := DEFAULT_AFT; EXP : in FIELD := DEFAULT_EXP); procedure PUT(ITEM : in NUM; FORE : in FIELD := DEFAULT_FORE; AFT : in FIELD := DEFAULT_AFT; EXP : in FIELD := DEFAULT_EXP); procedure GET(FROM : in STRING; ITEM : out NUM; LAST : out POSITIVE); procedure PUT(TO : out STRING; ITEM : in NUM; AFT : in FIELD := DEFAULT_AFT; EXP : in FIELD := DEFAULT_EXP); end FLOAT_IO; generic type NUM is delta <>; package FIXED_IO is DEFAULT_FORE : FIELD := NUM'FORE; DEFAULT_AFT : FIELD := NUM'AFT; DEFAULT_EXP : FIELD := 0; procedure GET(FILE : in FILE_TYPE; ITEM : out NUM; WIDTH : in FIELD := 0); procedure GET(ITEM : out NUM; WIDTH : in FIELD := 0); procedure PUT(FILE : in FILE_TYPE; ITEM : in NUM; FORE : in FIELD := DEFAULT_FORE; AFT : in FIELD := DEFAULT_AFT; EXP : in FIELD := DEFAULT_EXP); procedure PUT(ITEM : in NUM; FORE : in FIELD := DEFAULT_FORE; AFT : in FIELD := DEFAULT_AFT; EXP : in FIELD := DEFAULT_EXP); procedure GET(FROM : in STRING; ITEM : out NUM; LAST : out POSITIVE); procedure PUT(TO : out STRING; ITEM : in NUM; AFT : in FIELD := DEFAULT_AFT; EXP : in FIELD := DEFAULT_EXP); end FIXED_IO; -- Generic package for Input-Output of Enumeration Types generic type ENUM is (<>); package ENUMERATION_IO is DEFAULT_WIDTH : FIELD := 0; DEFAULT_SETTING : TYPE_SET := UPPER_CASE; procedure GET(FILE : in FILE_TYPE; ITEM : out ENUM); procedure GET(ITEM : out ENUM); procedure PUT(FILE : in FILE_TYPE; ITEM : in ENUM; WIDTH : in FIELD := DEFAULT_WIDTH; SET : in TYPE_SET := DEFAULT_SETTING); procedure PUT(ITEM : in ENUM; WIDTH : in FIELD := DEFAULT_WIDTH; SET : in TYPE_SET := DEFAULT_SETTING); procedure GET(FROM : in STRING; ITEM : out ENUM; LAST : out POSITIVE); procedure PUT(TO : out STRING; ITEM : in ENUM; SET : in TYPE_SET := DEFAULT_SETTING); end ENUMERATION_IO; -- Exceptions STATUS_ERROR : \uexception renames\n IO_EXCEPTIONS.STATUS_ERROR; MODE_ERROR : \uexception renames\n IO_EXCEPTIONS.MODE_ERROR; NAME_ERROR : \uexception renames\n IO_EXCEPTIONS.NAME_ERROR; USE_ERROR : \uexception renames\n IO_EXCEPTIONS.USE_ERROR; DEVICE_ERROR : \uexception renames\n IO_EXCEPTIONS.DEVICE_ERROR; END_ERROR : \uexception renames\n IO_EXCEPTIONS.END_ERROR; DATA_ERROR : \uexception renames\n IO_EXCEPTIONS.DATA_ERROR; LAYOUT_ERROR : \uexception renames\n IO_EXCEPTIONS.LAYOUT_ERROR; \uprivate\n -- implementation-dependent \uend\n TEXT_IO; :1419 14.4 \uExceptions in Input-Output\n The following exceptions can be raised by input-output operations. They are declared in the \vpackage IO_EXCEPTIONS\v1420., defined in section 14.5; this package is named in the context clause for each of the three input-output packages. Only outline descriptions are given of the conditions under which NAME_ERROR, USE_ERROR, and DEVICE_ERROR are raised; for full details see Appendix F. If more than one error condition exists, the corresponding exception that appears earliest in the following list is the one that is raised. The exception STATUS_ERROR is raised by an attempt to operate upon a \vfile\v1401. that is not open, and by an attempt to open a file that is already open. The exception MODE_ERROR is raised by an attempt to read from, or test for the end of, a file whose current mode is \vOUT_FILE\v1401., and also by an attempt to write to a file whose current mode is \vIN_FILE\v1401.. In the case of TEXT_IO, the exception MODE_ERROR is also raised by specifying a file whose current mode is OUT_FILE in a call of \vSET_INPUT\v1410., \vSKIP_LINE\v1412., \vEND_OF_LINE\v1412., \vSKIP_PAGE\v1412., or \vEND_OF_PAGE\v1412.; and by specifying a file whose current mode is IN_FILE in a call of \vSET_OUTPUT\v1410., \vSET_LINE_LENGTH\v1411., \vSET_PAGE_LENGTH\v1411., \vLINE_LENGTH\v1412., \vPAGE_LENGTH\v1412., \vNEW_LINE\v1412., or \vNEW_PAGE\v1412.. The exception NAME_ERROR is raised by a call of CREATE or \vOPEN\v1403. if the string given for the parameter \vNAME\v1401. does not allow the identification of an \vexternal file\v1401.. For example, this exception is raised if the string is improper, or, alternatively, if either none or more than one external file corresponds to the string. The exception USE_ERROR is raised if an operation is attempted that is not possible for reasons that depend on characteristics of the external file. For example, this exception is raised by the \vprocedure CREATE\v1403., among other circumstances, if the given mode is OUT_FILE but the form specifies an input only device, if the parameter FORM specifies invalid access rights, or if an external file with the given name already exists and overwriting is not allowed. The exception DEVICE_ERROR is raised if an input-output operation cannot be completed because of a malfunction of the underlying system. The exception END_ERROR is raised by an attempt to skip (read past) the end of a file. The exception DATA_ERROR may be raised by the \vprocedure READ\v1404. if the element read cannot be interpreted as a value of the required type. This exception is also raised by a \vprocedure GET\v1413. (defined in the \vpackage TEXT_IO\v1408.) if the input character sequence fails to satisfy the required syntax, or if the value input does not belong to the range of the required type or subtype. The exception LAYOUT_ERROR is raised (in text input-output) by \vCOL\v1412., \vLINE\v1412., or \vPAGE\v1412. if the value returned exceeds COUNT'LAST. The exception LAYOUT_ERROR is also raised on output by an attempt to set column or line numbers in excess of specified maximum line or page lengths, respectively (excluding the unbounded cases). It is also raised by an attempt to \vPUT\v1413. too many characters to a string. :1420 14.5 \uSpecification of the Package IO_Exceptions\n This package defines the exceptions needed by the packages SEQUENTIAL_IO, DIRECT_IO, and TEXT_IO. \upackage\n IO_EXCEPTIONS \uis\n STATUS_ERROR : \uexception\n; MODE_ERROR : \uexception\n; NAME_ERROR : \uexception\n; USE_ERROR : \uexception\n; DEVICE_ERROR : \uexception\n; END_ERROR : \uexception\n; DATA_ERROR : \uexception\n; LAYOUT_ERROR : \uexception\n; \uend\n IO_EXCEPTIONS; :1421 14.6 \uLow Level Input-Output\n A low level input-output operation is an operation acting on a physical device. Such an operation is handled by using one of the (overloaded) predefined procedures SEND_CONTROL and RECEIVE_CONTROL. A procedure SEND_CONTROL may be used to send control information to a physical device. A procedure RECEIVE_CONTROL may be used to monitor the execution of an input-output operation by requesting information from the physical device. Such procedures are declared in the standard package LOW_LEVEL_IO and have two parameters identifying the device and the data. However, the kinds and formats of the control information will depend on the physical characteristics of the machine and the device. Hence, the types of the parameters are implementation-defined. Overloaded definitions of these procedures should be provided for the supported devices. The visible part of the package defining these procedures is outlined as follows: \upackage\n LOW_LEVEL_IO \uis\n -- declarations of the possible types for DEVICE and DATA; -- declarations of overloaded procedures for these types: \uprocedure\n SEND_CONTROL (DEVICE : device_type; DATA : \uin out\n data_type); \uprocedure\n RECEIVE_CONTROL (DEVICE : device_type; DATA : \uin out\n data_type); end; The bodies of the procedures SEND_CONTROL and RECEIVE_CONTROL for various devices can be supplied in the body of the package LOW_LEVEL_IO. These procedure bodies may be written with code statements. :1422 14.7 \uExample of Input-Output\n The following example shows the use of some of the text input-output facilities in a dialogue with a user at a terminal. The user is prompted to type a color, and the program responds by giving the number of items of that color available in stock, according to an inventory. The default input and output files are used. For simplicity, all the requisite instantiations are given within one subprogram; in practice, a package, separate from the procedure, would be used. \uwith\n TEXT_IO; \uuse\n TEXT_IO; \uprocedure\n DIALOGUE \uis\n \utype\n COLOR \uis\n (WHITE, RED, ORANGE, YELLOW, GREEN, BLUE, BROWN); \upackage\n COLOR_IO \uis new\n ENUMERATION_IO(ENUM => COLOR); \upackage\n NUMBER_IO \uis new\n INTEGER_IO(INTEGER); \uuse\n COLOR_IO, NUMBER_IO; INVENTORY : \uarray\n (COLOR) \uof\n INTEGER := (20, 17, 43, 10, 28, 173, 87); CHOICE : COLOR; \uprocedure\n ENTER_COLOR (SELECTION : \uout\n COLOR) \uis\n \ubegin\n \uloop\n \ubegin\n PUT("Color selected: "); -- prompts user GET(SELECTION); -- accepts color typed, or raises exception \ureturn\n; \uexception\n \uwhen\n DATA_ERROR => PUT("Invalid color, try again. "); -- user has typed NEW_LINE(2); -- new line -- completes execution of the block statement \uend\n; \uend loop\n; -- repeats the block statement until color accepted \uend\n; \ubegin\n -- statements of DIALOGUE; NUMBER_IO.DEFAULT_WIDTH := 5; \uloop\n ENTER_COLOR(CHOICE); -- user types color and new line SET_COL(5); PUT(CHOICE); PUT(" items available:"); SET_COL(40); PUT(INVENTORY(CHOICE)); -- default width is 5 NEW_LINE; \uend loop\n; \uend\n DIALOGUE; Example of an interaction (characters typed by the user are italicized): Color selected: \uBlack\n Invalid color, try again. Color selected: \uBlue\n BLUE items available: 173 Color selected: \uYellow\n YELLOW items available: 10 :1500 A. \uPredefined Language Attributes\n This annex summarizes the definitions given elsewhere of the predefined language attributes. P'ADDRESS For a prefix P that denotes an object, a program unit, a label, or an entry: Yields the address of the first of the storage units allocated to P. For a subprogram, package, task unit, or label, this value refers to the machine code associated with the corresponding body or statement. For an entry for which an address clause has been given, the value refers to the corresponding hardware interrupt. The value of this attribute is of the type ADDRESS defined in the package SYSTEM. (See 13.7.2.) P'AFT For a prefix P that denotes a fixed point subtype: Yields the number of decimal digits needed after the point to accommodate the precision of the subtype P, unless the delta of the subtype P is greater than 0.1, in which case the attribute yields the value one. (P'AFT is the smallest positive integer N for which (10**N)*P'DELTA is greater than or equal to one.) The value of this attribute is of the type universal_integer. (See 3.5.10.) P'BASE For a prefix P that denotes a type or subtype: This attribute denotes the base type of P. It is only allowed as the prefix of the name of another attribute: for example, P'BASE'FIRST. (See 3.3.3.) P'CALLABLE For a prefix P that is appropriate for a task type: Yields the value FALSE when the execution of the task P is either completed or terminated, or when the task is abnormal; yields the value TRUE otherwise. The value of this attribute is of the predefined type BOOLEAN. (See 9.9.) P'CONSTRAINED For a prefix P that denotes an object of a type with discriminants: Yields the value TRUE if a discriminant constraint applies to the object P, or if the object is a constant (including a formal parameter or generic formal parameter of mode in); yields the value FALSE otherwise. If P is a generic formal parameter of mode in out, or if P is a formal parameter of mode in out or out and the type mark given in the corresponding parameter specification denotes an unconstrained type with discriminants, then the value of this attribute is obtained from that of the corresponding actual parameter. The value of this attribute is of the predefined type BOOLEAN. (See 3.7.4.) P'CONSTRAINED For a prefix P that denotes a private type or subtype: Yields the value FALSE if P denotes an unconstrained nonformal private type with discriminants; also yields the value FALSE if P denotes a generic formal private type and the associated actual subtype is either an unconstrained type with discriminants or an unconstrained array type; yields the value TRUE otherwise. The value of this attribute is of the predefined type BOOLEAN. (See 7.4.2.) P'COUNT For a prefix P that denotes an entry of a task unit: Yields the number of entry calls presently queued on the entry (if the attribute is evaluated within an accept statement for the entry P, the count does not include the calling task). The value of this attribute is of the type universal_integer. (See 9.9.) P'DELTA For a prefix P that denotes a fixed point subtype: Yields the value of the delta specified in the fixed accuracy definition for the subtype P. The value of this attribute is of the type universal_real. (See 3.5.10.) P'DIGITS For a prefix P that denotes a floating point subtype: Yields the number of decimal digits in the decimal mantissa of model numbers of the subtype P. (This attribute yields the number D of section 3.5.7.) The value of this attribute is of the type universal_integer. (See 3.5.8.) P'EMAX For a prefix P that denotes a floating point subtype: Yields the largest exponent value in the binary canonical form of model numbers of the subtype P. (This attribute yields the product 4*B of section 3.5.7.) The value of this attribute is of the type universal_integer. (See 3.5.8.) P'EPSILON For a prefix P that denotes a floating point subtype: Yields the absolute value of the difference between the model number 1.0 and the next model number above, for the subtype P. The value of this attribute is of the type universal_real. (See 3.5.8.) P'FIRST For a prefix P that denotes a scalar type, or a subtype of a scalar type: Yields the lower bound of P. The value of this attribute has the same type as P. (See 3.5.) P'FIRST For a prefix P that is appropriate for an array type, or that denotes a constrained array subtype: Yields the lower bound of the first index range. The value of this attribute has the same type as this lower bound. (See 3.6.2 and 3.8.2.) P'FIRST(N) For a prefix P that is appropriate for an array type, or that denotes a constrained array subtype: Yields the lower bound of the N-th index range. The value of this attribute has the same type as this lower bound. The argument N must be a static expression of type universal_integer. The value of N must be positive (nonzero) and no greater than the dimensionality of the array. (See 3.6.2 and 3.8.2.) P'FIRST_BIT For a prefix P that denotes a component of a record object: Yields the offset, from the start of the first of the storage units occupied by the component, of the first bit occupied by the component. This offset is measured in bits. The value of this attribute is of the type universal_integer. (See 13.7.2.) P'FORE For a prefix P that denotes a fixed point subtype: Yields the minimum number of characters needed for the integer part of the decimal representation of any value of the subtype P, assuming that the representation does not include an exponent, but includes a one-character prefix that is either a minus sign or a space. (This minimum number does not include superfluous zeros or underlines, and is at least two.) The value of this attribute is of the type universal_integer. (See 3.5.10.) P'IMAGE For a prefix P that denotes a discrete type or subtype: This attribute is a function with a single parameter. The actual parameter X must be a value of the base type of P. The result type is the predefined type STRING. The result is the image of the value of X, that is, a sequence of characters representing the value in display form. The image of an integer value is the corresponding decimal literal; without underlines, leading zeros, exponent, or trailing spaces; but with a one character prefix that is either a minus sign or a space. The image of an enumeration value is either the corresponding identifier in upper case or the corresponding character literal (including the two apostrophes); neither leading nor trailing spaces are included. The image of a character other than a graphic character is implementation-defined. (See 3.5.5.) P'LARGE For a prefix P that denotes a real subtype: The attribute yields the largest positive model number of the subtype P. The value of this attribute is of the type universal_real. (See 3.5.8 and 3.5.10.) P'LAST For a prefix P that denotes a scalar type, or a subtype of a scalar type: Yields the upper bound of P. The value of this attribute has the same type as P. (See 3.5.) P'LAST For a prefix P that is appropriate for an array type, or that denotes a constrained array subtype: Yields the upper bound of the first index range. The value of this attribute has the same type as this upper bound. (See 3.6.2 and 3.8.2.) P'LAST(N) For a prefix P that is appropriate for an array type, or that denotes a constrained array subtype: Yields the upper bound of the N-th index range. The value of this attribute has the same type as this upper bound. The argument N must be a static expression of type universal_integer. The value of N must be positive (nonzero) and no greater than the dimensionality of the array. (See 3.6.2 and 3.8.2.) P'LAST_BIT For a prefix P that denotes a component of a record object: Yields the offset, from the start of the first of the storage units occupied by the component, of the last bit occupied by the component. This offset is measured in bits. The value of this attribute is of the type universal_integer. (See 13.7.2.) P'LENGTH For a prefix P that is appropriate for an array type, or that denotes a constrained array subtype: Yields the number of values of the first index range (zero for a null range). The value of this attribute is of the type universal_integer. (See 3.6.2.) P'LENGTH(N) For a prefix P that is appropriate for an array type, or that denotes a constrained array subtype: Yields the number of values of the N-th index range (zero for a null range). The value of this attribute is of the type universal_integer. The argument N must be a static expression of type universal_integer. The value of N must be positive (nonzero) and no greater than the dimensionality of the array. (See 3.6.2 and 3.8.2.) P'MACHINE_EMAX For a prefix P that denotes a floating point type or subtype: Yields the largest value of exponent for the machine representation of the base type of P. The value of this attribute is of the type universal_integer. (See 13.7.3.) P'MACHINE_EMIN For a prefix P that denotes a floating point type or subtype: Yields the smallest (most negative) value of exponent for the machine representation of the base type of P. The value of this attribute is of the type universal_integer. (See 13.7.3.) P'MACHINE_MANTISSA For a prefix P that denotes a floating point type or subtype: Yields the number of digits in the mantissa for the machine representation of the base type of P (the digits are extended digits in the range 0 to P'MACHINE_RADIX - 1). The value of this attribute is of the type universal_integer. (See 13.7.3.) P'MACHINE_OVERFLOWS For a prefix P that denotes a real type or subtype: Yields the value TRUE if every predefined operation on values of the base type of P either provides a correct result, or raises the exception NUMERIC_ERROR in overflow situations; yields the value FALSE otherwise. The value of this attribute is of the predefined type BOOLEAN. (See 13.7.3.) P'MACHINE_RADIX For a prefix P that denotes a floating point type or subtype: Yields the value of the radix used by the machine representation of the base type of P. The value of this attribute is of the type universal_integer. (See 13.7.3.) P'MACHINE_ROUNDS For a prefix P that denotes a real type or subtype: Yields the value TRUE if every predefined arithmetic operation on values of the base type of P either returns an exact result or performs rounding; yields the value FALSE otherwise. The value of this attribute is of the predefined type BOOLEAN. (See 13.7.3.) P'MANTISSA For a prefix P that denotes a real subtype: Yields the number of binary digits in the binary mantissa of model numbers of the subtype P. (This attribute yields the number B of section 3.5.7 for a floating point type, or of section 3.5.9 for a fixed point type.) The value of this attribute is of the type universal_integer. (See 3.5.8 and 3.5.10.) P'POS For a prefix P that denotes a discrete type or subtype: This attribute is a function with a single parameter. The actual parameter X must be a value of the base type of P. The result type is the type universal_integer. The result is the position number of the value of the actual parameter. (See 3.5.5.) P'POSITION For a prefix P that denotes a component of a record object: Yields the offset, from the start of the first storage unit occupied by the record, of the first of the storage units occupied by the component. This offset is measured in storage units. The value of this attribute is of the type universal_integer. (See 13.7.2.) P'PRED For a prefix P that denotes a discrete type or subtype: This attribute is a function with a single parameter. The actual parameter X must be a value of the base type of P. The result type is the base type of P. The result is the value whose position number is one less than that of X. The exception CONSTRAINT_ERROR is raised if X equals P'BASE'FIRST. (See 3.5.5.) P'RANGE For a prefix P that is appropriate for an array type, or that denotes a constrained array subtype: Yields the first index range of P, that is, the range P'FIRST .. P'LAST. (See 3.6.2.) P'RANGE(N) For a prefix P that is appropriate for an array type, or that denotes a constrained array subtype: Yields the N-th index range of P, that is, the range P'FIRST(N) .. P'LAST(N). (See 3.6.2.) P'SAFE_EMAX For a prefix P that denotes a floating point type or subtype: Yields the largest exponent value in the binary canonical form of safe numbers of the base type of P. (This attribute yields the number E of section 3.5.7.) The value of this attribute is of the type universal_integer. (See 3.5.8.) P'SAFE_LARGE For a prefix P that denotes a real type or subtype: Yields the largest positive safe number of the base type of P. The value of this attribute is of the type universal_real. (See 3.5.8 and 3.5.10.) P'SAFE_SMALL For a prefix P that denotes a real type or subtype: Yields the smallest positive (nonzero) safe number of the base type of P. The value of this attribute is of the type universal_real. (See 3.5.8 and 3.5.10.) P'SIZE For a prefix P that denotes an object: Yields the number of bits allocated to hold the object. The value of this attribute is of the type universal_integer. (See 13.7.2.) P'SIZE For a prefix P that denotes any type or subtype: Yields the minimum number of bits that is needed by the implementation to hold any possible object of the type or subtype P. The value of this attribute is of the type universal_integer. (See 13.7.2.) P'SMALL For a prefix P that denotes a real subtype: Yields the smallest positive (nonzero) model number of the subtype P. The value of this attribute is of the type universal_real. (See 3.5.8 and 3.5.10.) P'STORAGE_SIZE For a prefix P that denotes an access type or subtype: Yields the total number of storage units reserved for the collection associated with the base type of P. The value of this attribute is of the type universal_integer. (See 13.7.2.) P'STORAGE_SIZE For a prefix P that denotes a task type or a task object: Yields the number of storage units reserved for each activation of a task of the type P or for the activation of the task object P. The value of this attribute is of the type universal_integer. (See 13.7.2.) P'SUCC For a prefix P that denotes a discrete type or subtype: This attribute is a function with a single parameter. The actual parameter X must be a value of the base type of P. The result type is the base type of P. The result is the value whose position number is one greater than that of X. The exception CONSTRAINT_ERROR is raised if X equals P'BASE'LAST. (See 3.5.5.) P'TERMINATED For a prefix P that is appropriate for a task type: Yields the value TRUE if the task P is terminated; yields the value FALSE otherwise. The value of this attribute is of the predefined type BOOLEAN. (See 9.9.) P'VAL For a prefix P that denotes a discrete type or subtype: This attribute is a special function with a single parameter X which can be of any integer type. The result type is the base type of P. The result is the value whose position number is the universal_integer value corresponding to X. The exception CONSTRAINT_ERROR is raised if the universal_integer value corresponding to X is not in the range P'POS(P'BASE'FIRST) .. P'POS(P'BASE'LAST). (See 3.5.5.) P'VALUE For a prefix P that denotes a discrete type or subtype: This attribute is a function with a single parameter. The actual parameter X must be a value of the predefined type STRING. The result type is the base type of P. Any leading and any trailing spaces of the sequence of characters that corresponds to X are ignored. For an enumeration type, if the sequence of characters has the syntax of an enumeration literal and if this literal exists for the base type of P, the result is the corresponding enumeration value. For an integer type, if the sequence of characters has the syntax of an integer literal, with an optional single leading character that is a plus or minus sign, and if there is a corresponding value in the base type of P, the result is this value. In any other case, the exception CONSTRAINT_ERROR is raised. (See 3.5.5.) P'WIDTH For a prefix P that denotes a discrete subtype: Yields the maximum image length over all values of the subtype P (the image is the sequence of characters returned by the attribute IMAGE). The value of this attribute is of the type universal_integer. (See 3.5.5.) :1600 B. \uPredefined Language Pragmas\n This annex defines the pragmas LIST, PAGE, and OPTIMIZE, and summarizes the definitions given elsewhere of the remaining language-defined pragmas. Pragma Meaning CONTROLLED Takes the simple name of an access type as the single argument. This pragma is only allowed immediately within the declarative part or package specification that contains the declaration of the access type; the declaration must occur before the pragma. This pragma is not allowed for a derived type. This pragma specifies that automatic storage reclamation must not be performed for objects designated by values of the access type, except upon leaving the innermost block statement, subprogram body, or task body that encloses the access type declaration, or after leaving the main program (see 4.8). ELABORATE Takes one or more simple names denoting library units as arguments. This pragma is only allowed immediately after the context clause of a compilation unit (before the subsequent library unit or secondary unit). Each argument must be the simple name of a library unit mentioned by the context clause. This pragma specifies that the corresponding library unit body must be elaborated before the given compilation unit. If the given compilation unit is a subunit, the library unit body must be elaborated before the body of the ancestor library unit of the subunit (see 10.5). INLINE Takes one or more names as arguments; each name is either the name of a subprogram or the name of a generic subprogram. This pragma is only allowed at the place of a declarative item in a declarative part or package specification, or after a library unit in a compilation, but before any subsequent compilation unit. This pragma specifies that the subprogram bodies should be expanded inline at each call whenever possible; in the case of a generic subprogram, the pragma applies to calls of its instantiations (see 6.3.2). INTERFACE Takes a language name and a subprogram name as arguments. This pragma is allowed at the place of a declarative item, and must apply in this case to a subprogram declared by an earlier declarative item of the same declarative part or package specification. This pragma is also allowed for a library unit; in this case the pragma must appear after the subprogram declaration, and before any subsequent compilation unit. This pragma specifies the other language (and thereby the calling conventions) and informs the compiler that an object module will be supplied for the corresponding subprogram (see 13.9). LIST Takes one of the identifiers ON or OFF as the single argument. This pragma is allowed anywhere a pragma is allowed. It specifies that listing of the compilation is to be continued or suspended until a LIST pragma with the opposite argument is given within the same compilation. The pragma itself is always listed if the compiler is producing a listing. MEMORY_SIZE Takes a numeric literal as the single argument. This pragma is only allowed at the start of a compilation, before the first compilation unit (if any) of the compilation. The effect of this pragma is to use the value of the specified numeric literal for the definition of the named number MEMORY_SIZE (see 13.7). OPTIMIZE Takes one of the identifiers TIME or SPACE as the single argument. This pragma is only allowed within a declarative part and it applies to the block or body enclosing the declarative part. It specifies whether time or space is the primary optimization criterion. PACK Takes the simple name of a record or array type as the single argument. The allowed positions for this pragma, and the restrictions on the named type, are governed by the same rules as for a representation clause. The pragma specifies that storage minimization should be the main criterion when selecting the representation of the given type (see 13.1). PAGE This pragma has no argument, and is allowed anywhere a pragma is allowed. It specifies that the program text which follows the pragma should start on a new page (if the compiler is currently producing a listing). PRIORITY Takes a static expression of the predefined integer subtype PRIORITY as the single argument. This pragma is only allowed within the specification of a task unit or immediately within the outermost declarative part of a main program. It specifies the priority of the task (or tasks of the task type) or the priority of the main program (see 9.8). SHARED Takes the simple name of a variable as the single argument. This pragma is allowed only for a variable declared by an object declaration and whose type is a scalar or access type; the variable declaration and the pragma must both occur (in this order) immediately within the same declarative part or package specification. This pragma specifies that every read or update of the variable is a synchronization point for that variable. An implementation must restrict the objects for which this pragma is allowed to objects for which each of direct reading and direct updating is implemented as an indivisible operation (see 9.11). STORAGE_UNIT Takes a numeric literal as the single argument. This pragma is only allowed at the start of a compilation, before the first compilation unit (if any) of the compilation. The effect of this pragma is to use the value of the specified numeric literal for the definition of the named number STORAGE_UNIT (see 13.7). SUPPRESS Takes as arguments the identifier of a check and optionally also the name of either an object, a type or subtype, a subprogram, a task unit, or a generic unit. This pragma is only allowed either immediately within a declarative part or immediately within a package specification. In the latter case, the only allowed form is with a name that denotes an entity (or several overloaded subprograms) declared immediately within the package specification. The permission to omit the given check extends from the place of the pragma to the end of the declarative region associated with the innermost enclosing block statement or program unit. For a pragma given in a package specification, the permission extends to the end of the scope of the named entity. If the pragma includes a name, the permission to omit the given check is further restricted: it is given only for operations on the named object or on all objects of the base type of a named type or subtype; for calls of a named subprogram; for activations of tasks of the named task type; or for instantiations of the given generic unit (see 11.7). SYSTEM_NAME Takes an enumeration literal as the single argument. This pragma is only allowed at the start of a compilation, before the first compilation unit (if any) of the compilation. The effect of this pragma is to use the enumeration literal with the specified identifier for the definition of the constant SYSTEM_NAME. This pragma is only allowed if the specified identifier corresponds to one of the literals of the type NAME declared in the package SYSTEM (see 13.7). :1700 C. \uPredefined Language Environment\n This annex outlines the specification of the package STANDARD containing all predefined identifiers in the language. The corresponding package body is implementation-defined and is not shown. The operators that are predefined for the types declared in the package STANDARD are given in comments since they are implicitly declared. Italics are used for pseudo-names of anonymous types (such as universal_real) and for undefined information (such as implementation_defined and any_fixed_point_type). package STANDARD is type BOOLEAN is (FALSE, TRUE); -- The predefined relational operators for this type are as follows: -- function "=" (LEFT, RIGHT : BOOLEAN) return BOOLEAN; -- function "/=" (LEFT, RIGHT : BOOLEAN) return BOOLEAN; -- function "<" (LEFT, RIGHT : BOOLEAN) return BOOLEAN; -- function "<=" (LEFT, RIGHT : BOOLEAN) return BOOLEAN; -- function ">" (LEFT, RIGHT : BOOLEAN) return BOOLEAN; -- function ">=" (LEFT, RIGHT : BOOLEAN) return BOOLEAN; -- The predefined logical operators and the predefined logical negation operator are as follows: -- function "and" (LEFT, RIGHT : BOOLEAN) return BOOLEAN; -- function "or" (LEFT, RIGHT : BOOLEAN) return BOOLEAN; -- function "xor" (LEFT, RIGHT : BOOLEAN) return BOOLEAN; -- function "not" (RIGHT : BOOLEAN) return BOOLEAN; -- The universal type universal_integer is predefined. type INTEGER is implementation_defined; -- The predefined operators for this type are as follows: -- function "=" (LEFT, RIGHT : INTEGER) return BOOLEAN; -- function "/=" (LEFT, RIGHT : INTEGER) return BOOLEAN; -- function "<" (LEFT, RIGHT : INTEGER) return BOOLEAN; -- function "<=" (LEFT, RIGHT : INTEGER) return BOOLEAN; -- function ">" (LEFT, RIGHT : INTEGER) return BOOLEAN; -- function ">=" (LEFT, RIGHT : INTEGER) return BOOLEAN; -- function "+" (RIGHT : INTEGER) return INTEGER; -- function "-" (RIGHT : INTEGER) return INTEGER; -- function "\uabs\n" (RIGHT : INTEGER) return INTEGER; -- function "+" (LEFT, RIGHT : INTEGER) return INTEGER; -- function "-" (LEFT, RIGHT : INTEGER) return INTEGER; -- function "*" (LEFT, RIGHT : INTEGER) return INTEGER; -- function "/" (LEFT, RIGHT : INTEGER) return INTEGER; -- function "rem" (LEFT, RIGHT : INTEGER) return INTEGER; -- function "mod" (LEFT, RIGHT : INTEGER) return INTEGER; -- function "**" (LEFT : INTEGER; RIGHT : INTEGER) return INTEGER; -- An implementation may provide additional predefined integer types. -- It is recommended that the names of such additional types end with -- INTEGER as in SHORT_INTEGER or LONG_INTEGER. The specification of -- each operator for the type universal_integer, or for any additional -- predefined integer type, is obtained by replacing INTEGER by -- the name of the type in the specification of the corresponding -- operator of the type INTEGER, except for the right operand of the -- exponentiating operator. -- The universal type universal_real is predefined. type FLOAT is implementation_defined; -- The predefined operators for this type are as follows: -- function "=" (LEFT, RIGHT : FLOAT) return BOOLEAN; -- function "/=" (LEFT, RIGHT : FLOAT) return BOOLEAN; -- function "<" (LEFT, RIGHT : FLOAT) return BOOLEAN; -- function "<=" (LEFT, RIGHT : FLOAT) return BOOLEAN; -- function ">" (LEFT, RIGHT : FLOAT) return BOOLEAN; -- function ">=" (LEFT, RIGHT : FLOAT) return BOOLEAN; -- function "+" (RIGHT : FLOAT) return FLOAT; -- function "-" (RIGHT : FLOAT) return FLOAT; -- function "\uabs\n" (RIGHT : FLOAT) return FLOAT; -- function "+" (LEFT, RIGHT : FLOAT) return FLOAT; -- function "-" (LEFT, RIGHT : FLOAT) return FLOAT; -- function "*" (LEFT, RIGHT : FLOAT) return FLOAT; -- function "/" (LEFT, RIGHT : FLOAT) return FLOAT; -- function "**" (LEFT : FLOAT; RIGHT : INTEGER) return FLOAT; -- An implementation may provide additional predefined floating point -- point types. It is recommended that the names of such additional -- types end with FLOAT as in SHORT_FLOAT or LONG_FLOAT. The -- specification of each operator for the type universal_real, or for -- any additional predefined floating point type, is obtained by -- replacing FLOAT by the name of the type in the specification of the -- corresponding operator of the type FLOAT. -- In addition, the following operators are predefined for universal types: -- function "*" (LEFT : universal_integer; RIGHT : universal_real) return universal_real; -- function "*" (LEFT : universal_real; RIGHT : universal_integer) return universal_real; -- function "/" (LEFT : universal_real; RIGHT : universal_integer) return universal_real; -- The type universal_fixed is predefined. The only operators declared for this type are -- function "*" (LEFT : any_fixed_point_type; RIGHT : any_fixed_point_type) return universal_fixed; -- function "/" (LEFT : any_fixed_point_type; RIGHT : any_fixed_point_type) return universal_fixed; -- The following characters form the standard ASCII character set. set. Character literals -- corresponding to control characters are not identifiers; they are indicated in italics in this definition. type CHARACTER is (nul, soh, stx, etx, eot, enq, ack, bel, bs, ht, lf, vt, ff, cr, so, si, dle, dc1, dc2, dc3, dc4, nak, syn, etb, can, em, sub, esc, fs, gs, rs, us, ' ', '!', '"', '#', '$', '%', '&', ''', '(', ')', '*', '+', ',', '-', '.', '/', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', ':', ';', '<', '=', '>', '?', '@', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '[', '\', ']', '~', '_', '`', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', '{', '|', '}', '~', del); for CHARACTER use -- 128 ASCII character set without holes (0, 1, 2, 3, 4, 5, ..., 125, 126, 127); -- The predefined operators for the type CHARACTER are the same as for any enumeration type. package ASCII is -- Control characters: NUL : constant CHARACTER := nul; SOH : constant CHARACTER := soh: STX : constant CHARACTER := stx; ETX : constant CHARACTER := etx; EOT : constant CHARACTER := eot; ENQ : constant CHARACTER := enq: ACK : constant CHARACTER := ack; BEL : constant CHARACTER := bel; BS : constant CHARACTER := bs; HT : constant CHARACTER := ht; LF : constant CHARACTER := lf; VT : constant CHARACTER := vt; FF : constant CHARACTER := ff; CR : constant CHARACTER := cr; SO : constant CHARACTER := so; SI : constant CHARACTER := si; DLE : constant CHARACTER := dle; DC1 : constant CHARACTER := dc1; DC2 : constant CHARACTER := dc2; DC3 : constant CHARACTER := dc3; DC4 : constant CHARACTER := dc4; NAK : constant CHARACTER := nak; SYN : constant CHARACTER := syn; ETB : constant CHARACTER := etb; CAN : constant CHARACTER := can; EM : constant CHARACTER := em: SUB : constant CHARACTER := sub; ESC : constant CHARACTER := esc; FS : constant CHARACTER := fs; GS : constant CHARACTER := gs; RS : constant CHARACTER := rs; US : constant CHARACTER := us; DEL : constant CHARACTER := del; -- Other characters: EXCLAM : constant CHARACTER := '!'; QUOTATION : constant CHARACTER := '"'; SHARP : constant CHARACTER := '#'; DOLLAR : constant CHARACTER := '$'; PERCENT : constant CHARACTER := '%'; AMPERSAND : constant CHARACTER := '&'; COLON : constant CHARACTER := ':'; SEMICOLON : constant CHARACTER := ';'; QUERY : constant CHARACTER := '?'; AT_SIGN : constant CHARACTER := '@'; L_BRACKET : constant CHARACTER := '['; BACK_SLASH: constant CHARACTER := '\'; R_BRACKET : constant CHARACTER := ']'; CIRCUMFLEX: constant CHARACTER := '~'; UNDERLINE : constant CHARACTER := '_'; GRAVE : constant CHARACTER := '`'; L_BRACE : constant CHARACTER := '{'; BAR : constant CHARACTER := '|'; R_BRACE : constant CHARACTER := '}'; TILDE : constant CHARACTER := '~'; -- Lower case letters: LC_A : constant CHARACTER := 'a'; ... LC_Z : constant CHARACTER := 'z'; end ASCII; -- Predefined subtypes: subtype NATURAL is INTEGER range 0 .. INTEGER'LAST; subtype POSITIVE is INTEGER range 1 .. INTEGER'LAST; -- Predefined string type: type STRING is \uarray\n(POSITIVE range <>) of CHARACTER; pragma PACK(STRING); -- The predefined operators for this type are as follows: -- function "=" (LEFT, RIGHT : STRING) return BOOLEAN; -- function "/=" (LEFT, RIGHT : STRING) return BOOLEAN; -- function "<" (LEFT, RIGHT : STRING) return BOOLEAN; -- function "<=" (LEFT, RIGHT : STRING) return BOOLEAN; -- function ">" (LEFT, RIGHT : STRING) return BOOLEAN; -- function ">=" (LEFT, RIGHT : STRING) return BOOLEAN; -- function "&" (LEFT : STRING; RIGHT : STRING) return STRING; -- function "&" (LEFT : CHARACTER; RIGHT : STRING) return STRING; -- function "&" (LEFT : STRING; RIGHT : CHARACTER) return STRING; -- function "&" (LEFT : CHARACTER; RIGHT : CHARACTER) return STRING; type DURATION is delta implementation_defined range implementation_defined; -- The predefined operators for the type DURATION are the same as for any fixed point type. -- The predefined exceptions: CONSTRAINT_ERROR : exception; NUMERIC_ERROR : exception; PROGRAM_ERROR : exception; STORAGE_ERROR : exception; TASKING_ERROR : exception; end STANDARD; Certain aspects of the predefined entities cannot be completely described in the language itself. For example, although the enumeration type BOOLEAN can be written showing the two enumeration literals FALSE and TRUE, the short-circuit control forms cannot be expressed in the language. Note: The language definition predefines the following library units: - The package CALENDAR (see 9.6) - The package SYSTEM (see 13.7) - The package MACHINE_CODE (if provided) (see 13.8) - The generic procedure UNCHECKED_DEALLOCATION (see 13.10.1) - The generic function UNCHECKED_CONVERSION (see 13.10.2) - The generic package SEQUENTIAL_IO (see 14.2.3) - The generic package DIRECT_IO (see 14.2.5) - The package TEXT_IO (see 14.3.10) - The package IO_EXCEPTIONS (see 14.5) - The package LOW_LEVEL_IO (see 14.6) :1800 D. \uGlossary\n This appendix is informative and is not part of the standard definition of the Ada programming language. Italicized terms in the abbreviated descriptions below either have glossary entries themselves or are described in entries for related terms. Accept statement. See entry. Access type. A value of an access type (an access value) is either a null value, or a value that designates an object created by an allocator. The designated object can be read and updated via the access value. The definition of an access type specifies the type of the objects designated by values of the access type. See also collection. Actual parameter. See parameter. Aggregate. The evaluation of an aggregate yields a value of a composite type. The value is specified by giving the value of each of the components. Either positional association or named association may be used to indicate which value is associated with which component. Allocator. The evaluation of an allocator creates an object and returns a new access value which designates the object. Array type. A value of an array type consists of components which are all of the same subtype (and hence, of the same type). Each component is uniquely distinguished by an index (for a one-dimensional array) or by a sequence of indices (for a multidimensional array). Each index must be a value of a discrete type and must lie in the correct index range. Assignment. Assignment is the operation that replaces the current value of a variable by a new value. An assignment statement specifies a variable on the left, and on the right, an expression whose value is to be the new value of the variable. Attribute. The evaluation of an attribute yields a predefined characteristic of a named entity; some attributes are functions. Block statement. A block statement is a single statement that may contain a sequence of statements. It may also include a declarative part, and exception handlers; their effects are local to the block statement. Body. A body defines the execution of a subprogram, package, or task. A body stub is a form of body that indicates that this execution is defined in a separately compiled subunit. Collection. A collection is the entire set of objects created by evaluation of allocators for an access type. Compilation unit. A compilation unit is the declaration or the body of a program unit, presented for compilation as an independent text. It is optionally preceded by a context clause, naming other compilation units upon which it depends by means of one more with clauses. Component. A component is a value that is a part of a larger value, or an object that is part of a larger object. Composite type. A composite type is one whose values have components. There are two kinds of composite type: array types and record types. Constant. See object. Constraint. A constraint determines a subset of the values of a type. A value in that subset satisfies the constraint. Context clause. See compilation unit. Declaration. A declaration associates an identifier (or some other notation) with an entity. This association is in effect within a region of text called the scope of the declaration. Within the scope of a declaration, there are places where it is possible to use the identifier to refer to the associated declared entity. At such places the identifier is said to be a simple name of the entity; the name is said to denote the associated entity. Declarative Part. A declarative part is a sequence of declarations. It may also contain related information such as subprogram bodies and representation clauses. Denote. See declaration. Derived Type. A derived type is a type whose operations and values are replicas of those of an existing type. The existing type is called the parent type of the derived type. Designate. See access type, task. Direct visibility. See visibility. Discrete Type. A discrete type is a type which has an ordered set of distinct values. The discrete types are the enumeration and integer types. Discrete types are used for indexing and iteration, and for choices in case statements and record variants. Discriminant. A discriminant is a distinguished component of an object or value of a record type. The subtypes of other components, or even their presence or absence, may depend on the value of the discriminant. Discriminant constraint. A discriminant constraint on a record type or private type specifies a value for each discriminant of the type. Elaboration. The elaboration of a declaration is the process by which the declaration achieves its effect (such as creating an object); this process occurs during program execution. Entry. An entry is used for communication between tasks. Externally, an entry is called just as a subprogram is called; its internal behavior is specified by one or more accept statements specifying the actions to be performed when the entry is called. Enumeration type. An enumeration type is a discrete type whose values are represented by enumeration literals which are given explicitly in the type declaration. These enumeration literals are either identifiers or character literals. Evaluation. The evaluation of an expression is the process by which the value of the expression is computed. This process occurs during program execution. Exception. An exception is an error situation which may arise during program execution. To raise an exception is to abandon normal program execution so as to signal that the error has taken place. An exception handler is a portion of program text specifying a response to the exception. Execution of such a program text is called handling the exception. Expanded name. An expanded name denotes an entity which is declared immediately within some construct. An expanded name has the form of a selected component: the prefix denotes the construct (a program unit; or a block, loop, or accept statement); the selector is the simple name of the entity. Expression. An expression defines the computation of a value. Fixed point type. See real type. Floating point type. See real type. Formal parameter. See parameter. Function. See subprogram. Generic unit. A generic unit is a template either for a set of subprograms or for a set of packages. A subprogram or package created using the template is called an instance of the generic unit. A generic instantiation is the kind of declaration that creates an instance. A generic unit is written as a subprogram or package but with the specification prefixed by a generic formal part which may declare generic formal parameters. A generic formal parameter is either a type, a subprogram, or an object. A generic unit is one of the kinds of program unit. Handler. See exception. Index. See array type. Index constraint. An index constraint for an array type specifies the lower and upper bounds for each index range of the array type. Indexed component. An indexed component denotes a component in an array. It is a form of name containing expressions which specify the values of the indices of the array component. An indexed component may also denote an entry in a family of entries. Instance. See generic unit. Integer type. An integer type is a discrete type whose values represent all integer numbers within a specific range. Lexical element. A lexical element is an identifier, a literal, a delimiter, or a comment. Limited type. A limited type is a type for which neither assignment nor the predefined comparison for equality is implicitly declared. All task types are limited. A private type can be defined to be limited. An equality operator can be explicitly declared for a limited type. Literal. A literal represents a value literally, that is, by means of letters and other characters. A literal is either a numeric literal, an enumeration literal, a character literal, or a string literal. Mode. See parameter. Model number. A model number is an exactly representable value of a real type. Operations of a real type are defined in terms of operations on the model numbers of the type. The properties of the model numbers and of their operations are the minimal properties preserved by all implementations of the real type. Name. A name is a construct that stands for an entity: it is said that the name denotes the entity, and that the entity is the meaning of the name. See also declaration, prefix. Named association. A named association specifies the association of an item with one or more positions in a list, by naming the positions. Object. An object contains a value. A program creates an object either by elaborating an object declaration or by evaluating an allocator. The declaration or allocator specifies a type for the object: the object can only contain values of that type. Operation. An operation is an elementary action associated with one or more types. It is either implicitly declared by the declaration of the type, or it is a subprogram that has a parameter or result of the type. Operator. An operator is an operation which has one or two operands. A unary operator is written before an operand; a binary operator is written between two operands. This notation is a special kind of function call. An operator can be declared as a function. Many operators are implicitly declared by the declaration of a type (for example, most type declarations imply the declaration of the equality operator for values of the type). Overloading. An identifier can have several alternative meanings at a given point in the program text: this property is called overloading. For example, an overloaded enumeration literal can be an identifier that appears in the definitions of two or more enumeration types. The effective meaning of an overloaded identifier is determined by the context. Subprograms, aggregates, allocators, and string literals can also be overloaded. Package. A package specifies a group of logically related entities, such as types, objects of those types, and subprograms with parameters of those types. It is written as a package declaration and a package body. The package declaration has a visible part, containing the declarations of all entities that can be explicitly used outside the package. It may also have a private part containing structural details that complete the specification of the visible entities, but which are irrelevant to the user of the package. The package body contains implementations of subprograms (and possibly tasks as other packages) that have been specified in the package declaration. A package is one of the kinds of program unit. Parameter. A parameter is one of the named entities associated with a subprogram, entry, or generic unit, and used to communicate with the corresponding subprogram body, accept statement or generic body. A formal parameter is an identifier used to denote the named entity within the body. An actual parameter is the particular entity associated with the corresponding formal parameter by a subprogram call, entry call, or generic instantiation. The mode of a formal parameter specifies whether the associated actual parameter supplies a value for the formal parameter, or the formal supplies a value for the actual parameter, or both. The association of actual parameters with formal parameters can be specified by named associations, by positional associations, or by a combination of these. Parent type. See derived type. Positional association. A positional association specifies the association of an item with a position in a list, by using the same position in the text to specify the item. Pragma. A pragma conveys information to the compiler. Prefix. A prefix is used as the first part of certain kinds of name. A prefix is either a function call or a name. Private part. See package. Private type. A private type is a type whose structure and set of values are clearly defined, but not directly available to the user of the type. A private type is known only by its discriminants (if any) and by the set of operations defined for it. A private type and its applicable operations are defined in the visible part of a package, or in a generic formal part. Assignment, equality, and inequality are also defined for private types, unless the private type is limited. Procedure. See subprogram. Program. A program is composed of a number of compilation units, one of which is a subprogram called the main program. Execution of the program consists of execution of the main program, which may invoke subprograms declared in the other compilation units of the program. Program unit. A program unit is any one of a generic unit, package, subprogram, or task unit. Qualified expression. A qualified expression is an expression preceded by an indication of its type or subtype. Such qualification is used when, in its absence, the expression might be ambiguous (for example as a consequence of overloading). Raising an exception. See exception. Range. A range is a contiguous set of values of a scalar type. A range is specified by giving the lower and upper bounds for the values. A value in the range is said to belong to the range. Range constraint. A range constraint of a type specifies a range, and thereby determines the subset of the values of the type that belong to the range. Real type. A real type is a type whose values represent approximations to the real numbers. There are two kinds of real type: fixed point types are specified by absolute error bound; floating point types are specified by a relative error bound expressed as a number of significant decimal digits. Record type. A value of a record type consists of components which are usually of different types or subtypes. For each component of a record value or record object, the definition of the record type specifies an identifier that uniquely determines the component within the record. Renaming declaration. A renaming declaration declares another name for an entity. Rendezvous. A rendezvous is the interaction that occurs between two parallel tasks when one task has called an entry of the other task, and a corresponding accept statement is being executed by the other task on behalf of the calling task. Representation clause. A representation clause directs the compiler in the selection of the mapping of a type, an object, or a task onto features of the underlying machine that executes a program. In some cases, representation clauses completely specify the mapping; in other cases, they provide criteria for choosing a mapping. Satisfy. See constraint, subtype. Scalar type. An object or value of a scalar type does not have components. A scalar type is either a discrete type or a real type. The values of a scalar type are ordered. Scope. See declaration. Selected component. A selected component is a name consisting of a prefix and of an identifier called the selector. Selected components are used to denote record components, entries, and objects designated by access values; they are also used as expanded names. Selector. See selected component. Simple name. See declaration, name. Statement. A statement specifies one or more actions to be performed during the execution of a program. Subcomponent. A subcomponent is either a component, or a component of another subcomponent. Subprogram. A subprogram is either a procedure or a function. A procedure specifies a sequence of actions and is invoked by a procedure call statement. A function specifies a sequence of actions and also returns a value called the result, and so a function call is an expression. A subprogram is written as a subprogram declaration, which specifies its name, formal parameters, and (for a function) its result; and a subprogram body which specifies the sequence of actions. The subprogram call specifies the actual parameters that are to be associated with the formal parameters. A subprogram is one of the kinds of program unit. Subtype. A subtype of a type characterizes a subset of the values of the type. The subset is determined by a constraint on the type. Each value in the set of values of a subtype belongs to the subtype and satisfies the constraint determining the subtype. Subunit. See body. Task. A task operates in parallel with other parts of the program. It is written as a task specification (which specifies the name of the task and the names and formal parameters of its entries), and a task body which defines its execution. A task unit is one of the kinds of program unit. A task type is a type that permits the subsequent declaration of any number of similar tasks of the type. A value of a task type is said to designate a task. Type. A type characterizes both a set of values, and a set of operations applicable to those values. A type definition is a language construct that defines a type. A particular type is either an access type, an array type, a private type, a record type, a scalar type, or a task type. Use clause. A use clause achieves direct visibility of declarations that appear in the visible parts of named packages. Variable. See object. Variant part. A variant part of a record specifies alternative record components, depending on a discriminant of the record. Each value of the discriminant establishes a particular alternative of the variant part. Visibility. At a given point in a program text, the declaration of an entity with a certain identifier is said to be visible if the entity is an acceptable meaning for an occurrence at that point of the identifier. The declaration is visible by selection at the place of the selector in a selected component or at the place of the name in a named association. Otherwise, the declaration is directly visible, that is, if the identifier alone has that meaning. Visible part. See package. With clause. See compilation unit. :1900 E. \uSyntax Summary\n 2.1 graphic_character ::= basic_graphic_character | lower_case_letter | other_special_character basic_graphic_character ::= upper_case_letter | digit | special_character | space_character basic_character ::= basic_graphic_character | format_effector 2.3 identifier ::= letter {[underline] letter_or_digit} letter_or_digit ::= letter | digit letter ::= upper_case_letter | lower_case_letter 2.4 numeric_literal ::= decimal_literal | based_literal 2.4.1 decimal_literal ::= integer [.integer] [exponent] integer ::= digit {[underline] digit} exponent ::= E [+] integer | E - integer 2.4.2 based_literal ::= base # based_integer [.based_integer] # [exponent] base ::= integer based_integer ::= extended_digit {[underline] extended_digit} extended_digit ::= digit | letter 2.5 character_literal ::= 'graphic_character' 2.6 string_literal ::= "{graphic_character}" 2.8 pragma ::= pragma identifier [(argument_association {, argument_association})]; argument_association ::= [argument_identifier =>] name | [argument_identifier =>] expression 3.1 basic_declaration ::= object_declaration | number_declaration | type_declaration | subtype_declaration | subprogram_declaration | package_declaration | task_declaration | generic_declaration | exception_declaration | generic_instantiation | renaming_declaration | deferred_constant_declaration 3.2 object_declaration ::= identifier_list : [constant] subtype_indication [:= expression]; | identifier_list : [constant] constrained_array_definition [:= expression]; number_declaration ::= identifier_list : constant := universal_static_expression; identifier_list ::= identifier {, identifier} 3.3.1 type_declaration ::= full_type_declaration | incomplete_type_declaration | private_type_declaration full_type_declaration ::= type identifier [discriminant_part] is type_definition; type_definition ::= enumeration_type_definition | integer_type_definition | real_type_definition | array_type_definition | record_type_definition | access_type_definition | derived_type_definition 3.3.2 subtype_declaration ::= subtype identifier is subtype_indication; subtype_indication ::= type_mark [constraint] type_mark ::= type_name | subtype_name constraint ::= range_constraint | floating_point_constraint | fixed_point_constraint | index_constraint | discriminant_constraint 3.4 derived_type_definition ::= new subtype_indication 3.5 range_constraint ::= range range range ::= range_attribute | simple_expression .. simple_expression 3.5.1 enumeration_type_definition ::= (enumeration_literal_specification {, enumeration_literal_specification}) enumeration_literal_specification ::= enumeration_literal enumeration_literal ::= identifier | character_literal 3.5.4 integer_type_definition ::= range_constraint 3.5.6 real_type_definition ::= floating_point_constraint | fixed_point_constraint 3.5.7 floating_point_constraint ::= floating_accuracy_definition [range_constraint] floating_accuracy_definition ::= digits static_simple_expression 3.5.9 fixed_point_constraint ::= fixed_accuracy_definition [range_constraint] fixed_accuracy_definition ::= delta static_simple_expression 3.6 array_type_definition ::= unconstrained_array_definition | constrained_array_definition unconstrained_array_definition ::= \uarray\n(index_subtype_definition {, index_subtype_definition}) of component_subtype_indication constrained_array_definition ::= \uarray\n index_constraint of component_subtype_indication index_subtype_definition ::= type_mark range <> index_constraint ::= (discrete_range {, discrete_range}) discrete_range ::= discrete_subtype_indication | range 3.7 record_type_definition ::= record component_list end record component_list ::= component_declaration {component_declaration} | {component_declaration} variant_part | \unull\n; component_declaration ::= identifier_list : component_subtype_definition [:= expression]; component_subtype_definition ::= subtype_indication 3.7.1 discriminant_part ::= (discriminant_specification {; discriminant_specification}) discriminant_specification ::= identifier_list : type_mark [:= expression] 3.7.2 discriminant_constraint ::= (discriminant_association {, discriminant_association}) discriminant_association ::= [discriminant_simple_name {| discriminant_simple_name} =>] expression 3.7.3 variant_part ::= case discriminant_simple_name is variant {variant} end case; variant ::= when choice {| choice} => component_list choice ::= simple_expression | discrete_range | others | component_simple_name 3.8 access_type_definition ::= \uaccess\n subtype_indication 3.8.1 incomplete_type_declaration ::= type identifier [discriminant_part]; 3.9 declarative_part ::= {basic_declarative_item} {later_declarative_item} basic_declarative_item ::= basic_declaration | representation_clause | use_clause later_declarative_item ::= body | subprogram_declaration | package_declaration | task_declaration | generic_declaration | use_clause | generic_instantiation body ::= proper_body | body_stub proper_body ::= subprogram_body | package_body | task_body 4.1 name ::= simple_name | character_literal | operator_symbol | indexed_component | slice | selected_component | attribute simple_name ::= identifier prefix ::= name | function_call 4.1.1 indexed_component ::= prefix(expression {, expression}) 4.1.2 slice ::= prefix(discrete_range) 4.1.3 selected_component ::= prefix.selector selector ::= simple_name | character_literal | operator_symbol | \uall\n 4.1.4 attribute ::= prefix'attribute_designator attribute_designator ::= simple_name [(universal_static_expression)] 4.3 aggregate ::= (component_association {, component_association}) component_association ::= [choice {| choice} => ] expression 4.4 expression ::= relation {and relation} | relation {\uand\n then relation} | relation {or relation} | relation {or else relation} | relation {xor relation} relation ::= simple_expression [relational_operator simple_expression] | simple_expression [not] in range | simple_expression [not] in type_mark simple_expression ::= [unary_adding_operator] term {binary_adding_operator term} term ::= factor {multiplying_operator factor} factor ::= primary [** primary] | \uabs\n primary | not primary primary ::= numeric_literal | \unull\n | aggregate | string_literal | name | allocator | function_call | type_conversion | qualified_expression | (expression) 4.5 logical_operator ::= \uand\n | or | xor relational_operator ::= = | /= | < | <= | > | >= binary_adding_operator ::= + | - | & unary_adding_operator ::= + | - multiplying_operator ::= * | / | mod | rem highest_precedence_operator ::= ** | \uabs\n | not 4.6 type_conversion ::= type_mark(expression) 4.7 qualified_expression ::= type_mark'(expression) | type_mark'aggregate 4.8 allocator ::= new subtype_indication | new qualified_expression 5.1 sequence_of_statements ::= statement {statement} statement ::= {label} simple_statement | {label} compound_statement simple_statement ::= null_statement | assignment_statement | procedure_call_statement | exit_statement | return_statement | goto_statement | entry_call_statement | delay_statement | abort_statement | raise_statement | code_statement compound_statement ::= if_statement | case_statement | loop_statement | block_statement | accept_statement | select_statement label ::= <> null_statement ::= \unull\n; 5.2 assignment_statement ::= variable_name := expression; 5.3 if_statement ::= if condition then sequence_of_statements {elsif condition then sequence_of_statements} [else sequence_of_statements] end if; condition ::= boolean_expression 5.4 case_statement ::= case expression is case_statement_alternative {case_statement_alternative} end case; case_statement_alternative ::= when choice {| choice } => sequence_of_statements 5.5 loop_statement ::= [loop_simple_name:] [iteration_scheme] loop sequence_of_statements end loop [loop_simple_name]; iteration_scheme ::= while condition | for loop_parameter_specification loop_parameter_specification ::= identifier in [reverse] discrete_range 5.6 block_statement ::= [block_simple_name:] [declare declarative_part] begin sequence_of_statements [exception exception_handler {exception_handler}] end [block_simple_name]; 5.7 exit_statement ::= exit [loop_name] [when condition]; 5.8 return_statement ::= return [expression]; 5.9 goto_statement ::= goto label_name; 6.1 subprogram_declaration ::= subprogram_specification; subprogram_specification ::= procedure identifier [formal_part] | function designator [formal_part] return type_mark designator ::= identifier | operator_symbol operator_symbol ::= string_literal formal_part ::= (parameter_specification {; parameter_specification}) parameter_specification ::= identifier_list : mode type_mark [:= expression] mode ::= [in] | in out | out 6.3 subprogram_body ::= subprogram_specification is [declarative_part] begin sequence_of_statements [exception exception_handler {exception_handler}] end [designator]; 6.4 procedure_call_statement ::= procedure_name [actual_parameter_part]; function_call ::= function_name [actual_parameter_part] actual_parameter_part ::= (parameter_association {, parameter_association}) parameter_association ::= [formal_parameter =>] actual_parameter formal_parameter ::= parameter_simple_name actual_parameter ::= expression | variable_name | type_mark(variable_name) 7.1 package_declaration ::= package_specification; package_specification ::= package identifier is {basic_declarative_item} [private {basic_declarative_item}] end [package_simple_name] package_body ::= package body package_simple_name is [declarative_part] [begin sequence_of_statements [exception exception_handler {exception_handler}]] end [package_simple_name]; 7.4 private_type_declaration ::= type identifier [discriminant_part] is [limited] private; deferred_constant_declaration ::= identifier_list : constant type_mark; 8.4 use_clause ::= use package_name {, package_name}; 8.5 renaming_declaration ::= identifier : type_mark renames object_name; | identifier : exception renames exception_name; | package identifier renames package_name; | subprogram_specification renames subprogram_or_entry_name; 9.1 task_declaration ::= task_specification; task_specification ::= task [type] identifier [is {entry_declaration} {representation_clause} end [task_simple_name]] task_body ::= task body task_simple_name is [declarative_part] begin sequence_of_statements [exception exception_handler {exception_handler}] end [task_simple_name]; 9.5 entry_declaration ::= entry identifier [(discrete_range)] [formal_part]; entry_call_statement ::= entry_name [actual_parameter_part]; accept_statement ::= \uaccept\n entry_simple_name [(entry_index)] [formal_part] [do sequence_of_statements end [entry_simple_name]]; entry_index ::= expression 9.6 delay_statement ::= delay simple_expression; 9.7 select_statement ::= selective_wait | conditional_entry_call | timed_entry_call 9.7.1 selective_wait ::= select select_alternative {or select_alternative} [else sequence_of_statements] end select; select_alternative ::= [when condition =>] selective_wait_alternative selective_wait_alternative ::= accept_alternative | delay_alternative | terminate_alternative accept_alternative ::= accept_statement [sequence_of_statements] delay_alternative ::= delay_statement [sequence_of_statements] terminate_alternative ::= terminate; conditional_entry_call ::= select entry_call_statement [sequence_of_statements] else sequence_of_statements end select; 9.7.3 timed_entry_call ::= select entry_call_statement [sequence_of_statements] or delay_alternative end select; 9.10 abort_statement ::= \uabort\n task_name {, task_name}; 10.1 compilation ::= {compilation_unit} compilation_unit ::= context_clause library_unit | context_clause secondary_unit library_unit ::= subprogram_declaration | package_declaration | generic_declaration | generic_instantiation | subprogram_body secondary_unit ::= library_unit_body | subunit library_unit_body ::= subprogram_body | package_body 10.1.1 context_clause ::= {with_clause {use_clause}} with_clause ::= with unit_simple_name {, unit_simple_name}; 10.2 body_stub ::= subprogram_specification is separate; | package body package_simple_name is separate; | task body task_simple_name is separate; subunit ::= separate (parent_unit_name) proper_body 11.1 exception_declaration ::= identifier_list : exception; 11.2 exception_handler ::= when exception_choice {| exception_choice} => sequence_of_statements exception_choice ::= exception_name | others 11.3 raise_statement ::= raise [exception_name]; 12.1 generic_declaration ::= generic_specification; generic_specification ::= generic_formal_part subprogram_specification | generic_formal_part package_specification generic_formal_part ::= generic {generic_parameter_declaration} generic_parameter_declaration ::= identifier_list : [in [out]] type_mark [:= expression]; | type identifier is generic_type_definition; | private_type_declaration | with subprogram_specification [is name]; | with subprogram_specification [is <>]; generic_type_definition ::= (<>) | range <> | digits <> | delta <> | array_type_definition | access_type_definition 12.3 generic_instantiation ::= package identifier is new generic_package_name [generic_actual_part]; | procedure identifier is new generic_procedure_name [generic_actual_part]; | function designator is new generic_function_name [generic_actual_part]; generic_actual_part ::= (generic_association {, generic_association}) generic_association ::= [generic_formal_parameter =>] generic_actual_parameter generic_formal_parameter ::= parameter_simple_name | operator_symbol generic_actual_parameter ::= expression | variable_name | subprogram_name | entry_name | type_mark 13.1 representation_clause ::= type_representation_clause | address_clause type_representation_clause ::= length_clause | enumeration_representation_clause | record_representation_clause 13.2 length_clause ::= for attribute use simple_expression; 13.3 enumeration_representation_clause ::= for type_simple_name use aggregate; 13.4 record_representation_clause ::= for type_simple_name use record [alignment_clause] {component_clause} end record; alignment_clause ::= at mod static_simple_expression; component_clause ::= component_name at static_simple_expression range static_range; 13.5 address_clause ::= for simple_name use at simple_expression; 13.8 code_statement ::= type_mark'record_aggregate; :2000 F. \uImplementation-Dependent Characteristics\n This appendix is not part of the standard definition of the Ada programming language. The Ada language definition allows for certain machine-dependences in a controlled manner. No machine-dependent syntax or semantic extensions or restrictions are allowed. The only allowed implementation-dependences correspond to implementation-dependent pragmas and attributes, certain machine-dependent conventions as mentioned in chapter 13, and certain allowed restrictions on representation clauses. The reference manual of each Ada implementation must include an appendix (called Appendix F) that describes all implementation-dependent characteristics. The appendix F for a given implementation must list in particular: (1) The form, allowed places, and effect of every implementation-dependent pragma. (2) The name and the type of every implementation-dependent attribute. (3) The specification of the package SYSTEM. (4) The list of all restrictions on representation clauses (see 13.1) (5) The conventions used for any implementation-generated name denoting implementation-dependent components (see 13.4). (6) The interpretation of expressions that appear in address clauses, including those for interrupts (see 13.5). (7) Any restriction on unchecked conversions (see 13.10.2). (8) Any implementation-dependent characteristics of the input-output packages (see 14).